Debugging output is not supported.

[JL2210]

When running ./build.sh gcc1 or anything that is compiled natively for ia16 from the build-ia16 repository, there are about ~1000 warnings that target system does not support debug output. How hard would it be to implement this? May I help?

[tkchia]

Hello @JL2210,

I imagine it will take quite a fair amount of work.

It should be quite feasible to tweak the GCC code's IA-16 backend to emit some form of debugging output (e.g. DWARF or stabs) in the intermediate .o files. But the real challenge is get the linker to propagate the information into the final .exe file, in a format that at least some existing DOS debuggers (e.g. Microsoft CodeView) can readily use.

If you do manage to implement this (☺), you would probably want to get and file a copyright assignment of your code to the Free Software Foundation, so that your code can eventually be included in mainline GCC. I have done this for my own modifications.

Thank you!

[JL2210]

OK. A workaround for now might be to disable the warning in gcc/opts.c.

[tkchia]

Hello @JL2210,

That is possible; but I am still rather leery of getting rid of the warning (since it may well be useful for users who specify -g and expect some debugging information in the final .exe). I will try to see if there might be a better third way.

Thank you!

[arbreng]

Hi,

What about the work to get this working for remote targets?

Even single stepping and breakpoints with no symbols would be amazing for debugging bootloader code in QEMU. Current GDB does very poorly at this.

I'm willing to dig in and help with this if I have a better idea of where to begin

[tkchia]

Thanks @arbreng, and my apologies for the belated reply.

What about the work to get this working for remote targets?

Even single stepping and breakpoints with no symbols would be amazing for debugging bootloader code in QEMU. Current GDB does very poorly at this.

I'm willing to dig in and help with this if I have a better idea of where to begin

Actually I am not sure myself of a good place to begin. :-| Since GDB is in the Binutils packages, though, I am guessing that it might be useful to try modifying the GDB code in binutils-ia16 to make it work better with qemu-system-i386.

Currently, I do not actually build GDB in my build scripts (build-ia16), and I do not really use GDB for debugging my 16-bit code. If you would like to do something in this direction, though, I would be happy to merge your changes in.

Thank you!

[asiekierka]

Some early patches which are just barely enough to compile, but not yet link, objects with DWARF2 debugging information (minus unwind information; anyhow, at least with segelf linking fails - .debug_frame! is missing).

• https://gist.github.com/asiekierka/bb5b43d3926035414b9a7b2b1a576397 - binutils patch:
  • the CIE offset alignment must be changed from -4 to -2, but it's set at an early stage (md_begin), before the .code16 statement is processed - as such, I had to add an ia16 architecture which works in CODE_16BIT by default, and a matching --16-segelf;
• https://gist.github.com/asiekierka/527be1b4d40b7a4eb5b00a40bb1dbdea - GCC patch:
  • the cfgexpand.c patch fixes an ICE, but I'm not sure if it does it correctly.

That's all the time I have for today, unfortunately. Thank you!

Notably, this doesn't seem to be enough to correctly emit line numbers. Odd.