Debug: evaluate a variable built with vbcc

[prb28]

I'm working on the amiga assembly extension for visual studio code.
I've added a feature to step and stop on breakpoints in C code. So it's possible to debug C and ASM in the same editor.

I would like to add the possibility to evaluate a C variable.
Someone has a clue to achieve that ?

My simple program:

#include <stdio.h>

extern int mul_by_ten(short input);

int main()
{
    short i;
    char* s="My Text";

    for (i = 0; i < 10; i++)
    {
        printf("Line %d\n", i);
        printf("10 * %d = %d\n", i, mul_by_ten(i));
        printf("--------\n");
    }

    return 0;
}

 }

Disassembled

c14234: 48 e7 20 20               movem.l   d2/a2, -(a7)
c14238: 45 fa 00 7a               lea.l     $94(pc), a2
c1423c: 74 00                     moveq     #$0, d2
c1423e: 60 3e                     bra.b     $5e
c14240: 30 02                     move.w    d2, d0
c14242: 48 c0                     ext.l     d0
c14244: 2f 00                     move.l    d0, -(a7)
c14246: 48 7a 00 44               pea.l     $6c(pc)
c1424a: 4e b9 00 c1 4b 1c         jsr       $c14b1c.l
c14250: 30 02                     move.w    d2, d0
c14252: 48 c0                     ext.l     d0
c14254: 2f 00                     move.l    d0, -(a7)
c14256: 4e b9 00 c0 2f f0         jsr       $c02ff0.l
c1425c: 2f 00                     move.l    d0, -(a7)
c1425e: 30 02                     move.w    d2, d0
c14260: 48 c0                     ext.l     d0
c14262: 2f 00                     move.l    d0, -(a7)
c14264: 48 7a 00 32               pea.l     $78(pc)
c14268: 4e b9 00 c1 4b 1c         jsr       $c14b1c.l
c1426e: 48 7a 00 38               pea.l     $88(pc)
c14272: 4e b9 00 c1 42 bc         jsr       $c142bc.l
c14278: 4f ef 00 1c               lea.l     $1c(a7), a7
c1427c: 52 42                     addq.w    #$1, d2
c1427e: b4 7c 00 0a               cmp.w     #$a, d2
c14282: 6d bc                     blt.b     $20
c14284: 70 00                     moveq     #$0, d0
c14286: 4c df 04 04               movem.l   (a7)+, d2/a2
c1428a: 4e 75                     rts

How do I know that 'i' is in d2?
How do I know the address of 's'?

[phx]

You don't know that without proper source level debugging information in the executable. vbcc can generate DWARF debug sections, which are not easy to parse but include everything you need to know.

DWARF doesn't work very well in hunk format executables though, and there are no debuggers which supports hunk format with DWARF, so we are enabling the -hunkdebug option by default for AmigaOS/68k. -hunkdebug generates SAS/C-style debug information, but only the LINE debug hunks, which I found documented in the Amiga Guru Book. Nothing else. Which means, with hunk format you are currently only getting the line numbers of the original source and nothing about variables.

[prb28]

I’m creating the debugger behavior and the parser, so I can try it...
Do you think the DWARF / hunk format is enough stable to be used?

[bebbo]

you could also support gcc and its stab (old gcc) debug format^^

[prb28]

Gcc can be tricky to install on a windows with m68k support, I like the simplicity of vbcc.
But yes, it’s an alternative.

[bebbo]

Originally Posted by prb28

Gcc can be tricky to install on a windows with m68k support, I like the simplicity of vbcc.
But yes, it’s an alternative.

try http://franke.ms/download/setup-amiga-gcc.exe

[prb28]

Both gcc and vbcc do DWARF2 and stabs.
Which one is the easiest to parse?
Are stabs and amiga hunk format compatible?

[prb28]

@bebbo thanks, I’ll try this install.

[MartinW]

@bebbo - does your gcc6 have prebuilt setups for MacOS as well yet?

I use vbcc over gcc because it was far simpler to install in Windows, MacOS and AOS 3.1 / 3.9 (in case I want to do some quick hacking / testing on real hardware).

[EDIT] PS: Very nice to see attention to Amiga C code in the extension. I've been using it for C since I first saw it.

[prb28]

I’v seen that stabs is obsolete on vbcc.
I’ll stick with DWARF2 but it should work with gcc.

[phx]

Originally Posted by prb28

I’m creating the debugger behavior and the parser, so I can try it...
Do you think the DWARF / hunk format is enough stable to be used?

Never really tried that. Just remove the -hunkdebug option in the first two lines of your config file (make a copy of it and rename it) for a test. Then vbcc will emit DWARF sections.

I guess one problem will be that sections in a hunk-format executable are unnamed, so you cannot easily find them. And another problem is that they are loaded into memory. Oh, and DWARF uses pointers and relocations at odd addresses, which LoadSeg() doesn't support...

The best solution to bring something like DWARF to the Amiga would be to have the linker parse the debug sections and convert them into a more compatible format in a HUNK_DEBUG hunk. Nothing you do on an evening, though...

[bebbo]

Originally Posted by MartinW

@bebbo - does your gcc6 have prebuilt setups for MacOS as well yet?

off topic: look here: https://github.com/bebbo/amiga-gcc/releases


regarding hunk + dwarf2: is there a magic cookie at start of the debug hunk which can be used to recognize a dwarf2 debug hunk?

[prb28]

That looks frightening!
Do vlink preserve the DWARF info in the exe?

[phx]

Originally Posted by bebbo

is there a magic cookie at start of the debug hunk which can be used to recognize a dwarf2 debug hunk?

Yes. The convention is to use a four-digit identifier as the first longword in a HUNK_DEBUG hunk. I don't have the Guru Book at hand, but from memory it is:

 0: HUNK_DEBUG
 4: hunk size in longwords
 8: section offset
12: four-digit ID (e.g. "LINE", for the SAS/C line-debug hunk)

The rest of the debug hunk can be used as you like. The section offset is always 0 in objects and patched by the linker when merging a section from several object files, which all have their own debug hunk. The debug hunks are not merged. There can be many of them for each section.

Originally Posted by prb28

That looks frightening!

Indeed, be very frightened!
Some months ago I implemented DWARF2 and 3 support in vasm, to make it automatically generate DWARF sections for source level debugging. It was... challenging.

Do vlink preserve the DWARF info in the exe?

Hunk-format objects have no concept of "debug sections", so they are stored as normal code or data sections with a ".debug_xyz" name. Currently vlink will just preserve those sections, which causes all sorts of problems.

[bebbo]

Originally Posted by phx

Yes. The convention is to use a four-digit identifier as the first longword in a HUNK_DEBUG hunk. I don't have the Guru Book at hand, but from memory it is:

 0: HUNK_DEBUG
 4: hunk size in longwords
 8: section offset
12: four-digit ID (e.g. "LINE", for the SAS/C line-debug hunk)

The rest of the debug hunk can be used as you like. The section offset is always 0 in objects and patched by the linker when merging a section from several object files, which all have their own debug hunk. The debug hunks are not merged. There can be many of them for each section.
...

* what is the 4 byte identifier used by vbcc/vlink/dwarf2?



* my gcc fork is using 2 debug sections per object file which are all together merged into one debug section for the binary. If I'd implement dwarf2 debug info for gcc/amiga hunk, I'd do it the same way -> one debug hunk per binary.

[prb28]

@bebbo: which debug info format did you use in your gcc fork?

[bebbo]

Originally Posted by prb28

@bebbo: which debug info format did you use in your gcc fork?

the .stab format since it was used back then and easier to re-implement. I changed the intermediate format (hunk objects) but the binary format should be identical to the one at that time.

[phx]

Originally Posted by bebbo

* what is the 4 byte identifier used by vbcc/vlink/dwarf2?

It doesn't exist yet. And whether I will ever implement it depends on the demand and if there will be any consumers (i.e. debuggers) for it.

[prb28]

Originally Posted by MartinW

[EDIT] PS: Very nice to see attention to Amiga C code in the extension. I've been using it for C since I first saw it.

Thanks, hope it helps some nostalgic developers


The preview of 0.17 version already has a step debugging in ASM showing the C source, but you have to step several times for one line of C code and you do not know the variables values.



I don't know if it is already useful as it is without variable value evaluation which is expected for a 'normal' debugger.


As I understand for amigaos there are some build environments for C as:

• SAS/C
• Barfly assembler package
• StormC
• etc.

They use as debug info:

• Line debug of SAS/C
• stabs (for gcc derivatives)
• other custom formats

I imagine that StormC has a variable evaluation and BDebug (Barfly) not. Is that right ?


Now, for my needs, I've the choice of:

• vbcc with an experimental DWARF2/Hunk format with possible issues during the execution
• gcc fork from bebbo with stabs format

I'm reading some docs about these formats to see if it's not a too big investment.


Other alternatives can be the use of 'debug.lib' and listen to serial output, so the developer can send messages that are displayed in the debugger.


Do you have in mind some other alternative?

[prb28]

@bebbo: maybe connecting to your gdbserver is a better way.
I'll try it with vscode.