Messed up static / global variable preview and when using watch

tehKaiN commented 4 years ago

Hi,

I'm having some problems with debugger features:

variables in Variables and Watch panels have wrong values, their addresses doesn't match. If I do the watch for specific address of a variable (which e.g. I print out in log) the values are correct.
static variables are shown in Globals subcategory, not Static.

I'm using custom CMake to generate .map, .elf and hunk files in similar manner as your makefile, but perhaps I've messed up something. I'll try to debug it myself but I need a little guidance from you. How does vscode know at which address is given static/global/local variable?

my C flags: -m68000 -fomit-frame-pointer -nostdlib -Wno-unused-function -Wno-volatile-register-var -fno-tree-loop-distribution -flto -fwhole-program -Wno-old-style-declaration
my link flags -Wl,--emit-relocs,-Ttext=0
I'm generating .map file using -Wl,-Map=germz.map linker flag.
I'm using command ${OBJDUMP} --disassemble -S ${GERMZ_EXECUTABLE} > germz.s to generate disassembly, where ${OBJDUMP} is objdump from your compiler suite.
link to CMake toolchain file if you're interested: https://github.com/AmigaPorts/AmigaCMakeCrossToolchains/blob/bartman/m68k-bartman.cmake

EDIT: The local variables are most of the time okay, the problem is with static/global vars.

BartmanAbyss commented 4 years ago

Yeah, there are some limitations. You can have only 1 CODE (.text), 1 DATA (.data/.rodata) and 1 BSS section/hunk (.bss). GDB doesn't have better support for relocating. (btw. the disassembly and map files are not needed for the debugger, it's just a convenience for you to check the generated code)

tehKaiN commented 4 years ago

So I assume I must somehow merge my sections. I'm an elf/hunk noob so after a bit of reading I still don't know which way I should go. Could you tell me if there's something wrong only with my hunk, or is the root cause in elf file? My elf has following sections:

Nr             Name                Type           Address             Offset              Size                Link           Info           AddrAlign           EntSize             Flags          
0                                  SHT_NULL       0x00000000          0x00000000          0x00000000          0x00000000     0x00000000     0x00000000          0x00000000                         
1              .text               SHT_PROGBITS   0x00000000          0x00002000          0x00019548          0x00000000     0x00000000     0x00000004          0x00000000          Alloc|Exec     
2              .rela.text          SHT_RELA       0x00000000          0x000BC398          0x00009D74          0x0000001B     0x00000001     0x00000004          0x0000000C          InfoLink       
3              .rodata             SHT_PROGBITS   0x00019548          0x0001B548          0x000040BC          0x00000000     0x00000000     0x00000002          0x00000000          Alloc          
4              .rela.rodata        SHT_RELA       0x00000000          0x000C610C          0x000004F8          0x0000001B     0x00000003     0x00000004          0x0000000C          InfoLink       
5              .data               SHT_PROGBITS   0x0001F604          0x0001F604          0x0000117C          0x00000000     0x00000000     0x00000004          0x00000000          Write|Alloc    
6              .rela.data          SHT_RELA       0x00000000          0x000C6604          0x00000180          0x0000001B     0x00000005     0x00000004          0x0000000C          InfoLink       
7              .MEMF_CHIP          SHT_PROGBITS   0x00020780          0x00020780          0x00000004          0x00000000     0x00000000     0x00000002          0x00000000          Write|Alloc    
8              .bss                SHT_NOBITS     0x00020784          0x00020784          0x00003170          0x00000000     0x00000000     0x00000004          0x00000000          Write|Alloc    
9              .comment            SHT_PROGBITS   0x00000000          0x00020784          0x00000012          0x00000000     0x00000000     0x00000001          0x00000001          Merge|Strings  
10             .gnu.debuglto_.debug_infoSHT_PROGBITS   0x00000000          0x00020796          0x0001F859          0x00000000     0x00000000     0x00000001          0x00000000                         
11             .rela.gnu.debuglto_.debug_infoSHT_RELA       0x00000000          0x000C6784          0x00002BA4          0x0000001B     0x0000000A     0x00000004          0x0000000C          InfoLink       
12             .gnu.debuglto_.debug_abbrevSHT_PROGBITS   0x00000000          0x0003FFEF          0x00002A4B          0x00000000     0x00000000     0x00000001          0x00000000                         
13             .gnu.debuglto_.debug_lineSHT_PROGBITS   0x00000000          0x00042A3A          0x000040BF          0x00000000     0x00000000     0x00000001          0x00000000                         
14             .gnu.debuglto_.debug_strSHT_PROGBITS   0x00000000          0x00046AF9          0x0000086A          0x00000000     0x00000000     0x00000001          0x00000000                         
15             .debug_aranges      SHT_PROGBITS   0x00000000          0x00047368          0x00000440          0x00000000     0x00000000     0x00000008          0x00000000                         
16             .rela.debug_aranges SHT_RELA       0x00000000          0x000C9328          0x00000330          0x0000001B     0x0000000F     0x00000004          0x0000000C          InfoLink       
17             .debug_info         SHT_PROGBITS   0x00000000          0x000477A8          0x000365BB          0x00000000     0x00000000     0x00000001          0x00000000                         
18             .rela.debug_info    SHT_RELA       0x00000000          0x000C9658          0x00009C48          0x0000001B     0x00000011     0x00000004          0x0000000C          InfoLink       
19             .debug_abbrev       SHT_PROGBITS   0x00000000          0x0007DD63          0x000056EC          0x00000000     0x00000000     0x00000001          0x00000000                         
20             .debug_line         SHT_PROGBITS   0x00000000          0x0008344F          0x000212F8          0x00000000     0x00000000     0x00000001          0x00000000                         
21             .rela.debug_line    SHT_RELA       0x00000000          0x000D32A0          0x0001E69C          0x0000001B     0x00000014     0x00000004          0x0000000C          InfoLink       
22             .debug_frame        SHT_PROGBITS   0x00000000          0x000A4748          0x0000CE9C          0x00000000     0x00000000     0x00000004          0x00000000                         
23             .rela.debug_frame   SHT_RELA       0x00000000          0x000F193C          0x00003510          0x0000001B     0x00000016     0x00000004          0x0000000C          InfoLink       
24             .debug_str          SHT_PROGBITS   0x00000000          0x000B15E4          0x00000B8E          0x00000000     0x00000000     0x00000001          0x00000000                         
25             .debug_ranges       SHT_PROGBITS   0x00000000          0x000B2172          0x000000A8          0x00000000     0x00000000     0x00000001          0x00000000                         
26             .rela.debug_ranges  SHT_RELA       0x00000000          0x000F4E4C          0x00000030          0x0000001B     0x00000019     0x00000004          0x0000000C          InfoLink       
27             .symtab             SHT_SYMTAB     0x00000000          0x000B221C          0x00007190          0x0000001C     0x000005A9     0x00000004          0x00000010                         
28             .strtab             SHT_STRTAB     0x00000000          0x000B93AC          0x00002FEA          0x00000000     0x00000000     0x00000001          0x00000000                         
29             .shstrtab           SHT_STRTAB     0x00000000          0x000F4E7C          0x00000120          0x00000000     0x00000000     0x00000001          0x00000000

My hunk has following contents:

-------------------------------------------
HUNK HEADER :
-------------------------------------------
File size = 160260 bytes
Number of hunks = 5
Number of first hunk = 0
Number of last hunk = 4
Size of 0 hunk = 25939
Size of 1 hunk = 4144
Size of 2 hunk = 1120
Size of 3 hunk = 1073741826
Size of 4 hunk = 3165
-------------------------------------------
HUNK NUMBER 0 :
-------------------------------------------
Position = 40
HUNK_CODE (0x3E9)
Size in long words = 25939, bytes = 103756
pos: 48
-------------------------------------------
Position = 103804
HUNK_SYMBOL (0x3F0)
symbols here
-------------------------------------------
Position = 118684
HUNK_RELOC32 (0x3EC)
Number of Offsets = 1194
Numbers of hunk = 4
pos: 118696
Number of Offsets = 2
Numbers of hunk = 3
pos: 123480
Number of Offsets = 61
Numbers of hunk = 2
pos: 123496
Number of Offsets = 873
Numbers of hunk = 1
pos: 123748
Number of Offsets = 1229
Numbers of hunk = 0
pos: 127248
-------------------------------------------
Position = 132168
HUNK_END (0x3F2)
-------------------------------------------
HUNK NUMBER 1 :
-------------------------------------------
Position = 132172
HUNK_DATA (0x3EA)
Size in long words = 4144, bytes = 16576
pos: 132180
-------------------------------------------
Position = 148756
HUNK_SYMBOL (0x3F0)
symbols here
-------------------------------------------
Position = 150704
HUNK_RELOC32 (0x3EC)
Number of Offsets = 106
Numbers of hunk = 0
pos: 150716
-------------------------------------------
Position = 151144
HUNK_END (0x3F2)
-------------------------------------------
HUNK NUMBER 2 :
-------------------------------------------
Position = 151148
HUNK_DATA (0x3EA)
Size in long words = 1120, bytes = 4480
pos: 151156
-------------------------------------------
Position = 155636
HUNK_SYMBOL (0x3F0)
symbols here
-------------------------------------------
Position = 156160
HUNK_RELOC32 (0x3EC)
Number of Offsets = 8
Numbers of hunk = 2
pos: 156172
Number of Offsets = 21
Numbers of hunk = 1
pos: 156212
Number of Offsets = 3
Numbers of hunk = 0
pos: 156304
-------------------------------------------
Position = 156320
HUNK_END (0x3F2)
-------------------------------------------
HUNK NUMBER 3 :
-------------------------------------------
Position = 156324
HUNK_DATA (0x3EA)
Size in long words = 2, bytes = 8
pos: 156332
-------------------------------------------
Position = 156340
HUNK_SYMBOL (0x3F0)
symbols here
-------------------------------------------
Position = 156396
HUNK_END (0x3F2)
-------------------------------------------
HUNK NUMBER 4 :
-------------------------------------------
Position = 156400
HUNK_BSS (0x3EB)
Allocable memory = 3165
-------------------------------------------
Position = 156408
HUNK_SYMBOL (0x3F0)
symbols here
-------------------------------------------
Position = 160256
HUNK_END (0x3F2)
-------------------------------------------

BartmanAbyss commented 4 years ago

Hmm.. it seems you have 3 data hunks. 2 is generally ok (1 regular, 1 chipmem), however only the first data hunk will support relocation with GDB. I can't really comment on your specifics, my tip is: check the elf/hunk output of the template project and compare.

tehKaiN commented 4 years ago

A bit of progress here. I was building using CMake and linked some .c files into a library, which in turn was linked with executable's .c files. When I changed CMake library generation to object-style library (just a bunch of .o files), I've got rid of one data hunk. It still didn't helped me, though.

Upon closer inspection I see that your .elf doesn't have .rela.data and .rela.rodata sections and indeed, multiple HUNK_RELOC32 tables are probably the reason for wrong behavior. I've managed to reproduce generation of at least .rela.rodata using simple code. In your example project, try creating test.c and add inside it:

// some magic to ensure that code gets generated
volatile int *pAddr = (volatile int *)0xDEAD;

static const char *s_pReadOnly[] = {
    "Joy 1", "Joy 2", "Joy 3", "Joy 4", "WSAD", "Arrows", "CPU", "Idle", "Off"
};

const char* returnReadOnly(void) {
    return s_pReadOnly[*pAddr];
}

then call those fns from main.c like:

    const char* returnReadOnly(void);

    KPrintF("Hello debugger from Amiga! %s\n", returnReadOnly());
    KPrintF("Hello debugger from Amiga! %s\n", returnReadOnly());

Build using your makefile. When stepping through code, preview of s_pReadOnly and s_pWritable should be messed up.

tehKaiN commented 4 years ago

I've modified linker script so that it will merge .data and .rodata sections:

got the original one by executing m68k-amiga-elf-ld --verbose, saved to file
linked with -T link.ld -L /ld/dir
merged sections with:

  .data           :
  {
        *(.rodata .rodata.* .gnu.linkonce.r.*) *(.rodata1)
        *(.data .data.* .gnu.linkonce.d.*) *(.data1)
        SORT(CONSTRUCTORS)
  }

removed definitions of .data and .rodata

Now my Hunk has following sections:

hunk 0 with sections HUNK_CODE, HUNK_SYMBOL, HUNK_RELOC32 - all fns are here
hunk 1 with sections HUNK_DATA, HUNK_SYMBOL, HUNK_RELOC32 - all vars are here, also __fini_*, __init_*, __preinit_* etc.
hunk 2 with sections HUNK_DATA, HUNK_SYMBOL - single var here, that's my MEMF_CHIP
hunk 3 with sections HUNK_BSS, HUNK_SYMBOL

Now the only difference between my hunk and yours from example project is that you don't have HUNK_RELOC32 in data hunk, and I have one section less than you (no incbin one since I use files). I've tried to merge .data and .text sections but then the debugger breakpoints stopped working.

Any ideas?

BartmanAbyss commented 4 years ago

your hunks look fine to me. what's the problem still? anyway, you have to keep .text for code.

tehKaiN commented 4 years ago

The problem is a mismatch between watch / variable view's addresses and true addresses, as in picture below

obraz

My code from https://github.com/BartmanAbyss/vscode-amiga-debug/issues/11#issuecomment-650727711 should reproduce that in your example too, when put into separate file.

BartmanAbyss commented 4 years ago

Completely reworked the relocation in 2a4d42b4a0ec59235195513a1ca8a4a8865203ff. Should now support arbitrary number of sections/hunks. Please try the new version and close issue if resolved.

Also, elf2hunk now dumps ELF section/HUNK hunk information if you pass the additional parameter -v. Might come handy for debugging.

tehKaiN commented 4 years ago

Would it be too much if I ask you for an extension build? Or some kind of instructions how to build it and generate vsix?

All my changes so far were based on modifying .js files directly and backporting changes to .ts for pull request. I Guess I'll have to set it up correctly now.

BartmanAbyss commented 4 years ago

Sure. Try this. Get the source from github. Enter the directory. In a DOS box, type "npm install", then "vsce package". You need to have node.js installed, and you can install vsce with "npm install -g vsce"

BartmanAbyss commented 4 years ago

If that's too complicated for you, just get winuae-gdb.exe and m68k-amiga-elf-gdb.exe from github and overwrite in your installed extension dir (c:\users....vscode\extensions\bartmanabyss......)

tehKaiN commented 4 years ago

works! 🎉

BartmanAbyss / vscode-amiga-debug

Messed up static / global variable preview and when using watch #11