Devpac Debug hunks

[phx]

When you assemble with debug info enabled in Devpac, you get a free floating

HUNK_DEBUG

labeled

HEADDBGV01

, directly following the header, and debug hunks labeled

HCLN

for each section.

Is the Devpac debug format documented somewhere? The

HCLN

parts certainly tell you which source text line number belongs to which hunk offset?

[a/b]

Some info here http://eab.abime.net/showthread.php?t=63895 that leads to wiki: http://amiga-dev.wikidot.com/file-format:hunk#toc23

[phx]

The HEADDBGV01 part is still mysterious, but HCLN seems sufficiently reengineered. Thanks a lot!

I guess that Devpac's MonAm will read both, Devpac-HCLN and SAS/C-LINE DEBUG hunks. So there is no real need to support HCLN, but the compressed format saves quite some space.

[kamelito]

I sent a mail to the developer, don’t know if his address is still valid though.

[phx]

Great!

Maybe I can implement it as an alternative line-debug format in vasm, once I have all information.

[kamelito]

His answer.
« Wow, hi Kamel, yeah that is a serious memory test.

If HEADDBGV01 is unique to Devpac, then I probably invented it, and it might be similar to debug formats on the Atari ST (which I have slightly better memory of).
If it is not unique to Devpac, then it may have come from Lattice C - they created debug formats when they did their C compiler and I would have re-used their stuff, as HiSoft had the license to port it to the Atari.

Sorry but that's about all I can recall from back then. »

[phx]

Originally Posted by kamelito

If HEADDBGV01 is unique to Devpac, then I probably invented it, and it might be similar to debug formats on the Atari ST (which I have slightly better memory of).

Now I'm unsure. Did I see HEADDBGV01 also in SAS/C output? Have to check that tomorrow.

Otherwise, I'm also interested in Atari object file formats.
Especially in the DRI object file format Devpac generates. I reengineered some reloc types, like 0x0000 (no relocation), 0x0001 (data reloc), 0x002 (text reloc), 0x0003 (bss reloc), 0x0004 (external references). But lots of details are missing to output real DRI objects. The format is nowhere documented, AFAIK. Would be great to preserve it.

Sorry but that's about all I can recall from back then. »

Thanks, nevertheless!

[kamelito]

More info, I asked Andy if he wanna join to answer directly here will see.
« I found the source code to a linker I wrote (I don’t even remember writing a linker after I left HiSoft, but clearly I did, even though I have no idea why), and it seems to emit Amiga debug info.

I also found the source to my Atari debugger which read Atari debug info.

I did find the source code to devpac, but it is in encrypted LZH and ARC files. Project for another day… »

[phx]

Sounds great! Any information is much appreciated.

[kamelito]

Andy sent me 3 C files I’ll upload them during the day in the zone.

update: files put in the zones for PHX I hope that it'll help improve Devpac support.

[phx]

Wow! That's great. Seems to include a lot of information I need. I will work through it in the following weeks. Maybe I can add HCLN source level debugging to the Amiga output module and real DRI object files for the Atari output module now. Thanks!

Eventually I should also document the format on my home page, so the information is preserved for the future.

[DevpacDude]

Hope my old code is useful. It was some of the earliest real C code I ever wrote, so forgive me.

[kamelito]

Thanks Andy, it is much appreciated, it would be nice to have Devpac open sourced but it is in Hisoft hands.

[Debvgger]

Thanks a lot for sharing this :-)

[tolkien]

Originally Posted by DevpacDude

Hope my old code is useful. It was some of the earliest real C code I ever wrote, so forgive me.

Oh man...Devpac hero! What a legend. Thanks for sharing this info to vasm hero

[Exodous]

Originally Posted by kamelito

Thanks Andy, it is much appreciated, it would be nice to have Devpac open sourced but it is in Hisoft hands.

+1 to this



I've been doing some work resourcing it with a view to fixing some bugs with source that assembles fine in v2.x but flat out refuses in v3.x, yet assembles with other assemblers I've tried and even shows correctly in MonAm.


It would be so much easier if the code was available.

[Bruce Abbott]

Originally Posted by Exodous

source that assembles fine in v2.x but flat out refuses in v3.x

Can you show us an example?

[Exodous]

I would, but everything now seems to be assembling fine on my Devpac 3 installation

On My A500 and then A1200, I originally had Devpac 2 and wrote a load of code, most never to be looked at again. When I upgraded my A500 to Kickstart 2.0.4, I upgraded to Devpac 3, specifically 3.04.

Last year, I restored my Amiga installation in WinUAE from the Quarterback backups of my physical A1200 and started looking through my old code.

There were a few different errors I had assembling Devpac 2 code in Devpac 3, but the most common one I can remember was code with "bset.b #<number_0_to_7>,<memory_address>" which failed to assemble with an error like "invalid size". I could fix it by altering my code to remove the .b as this is implied with the destination being a memory address anyway, but it assembled fine in vasm with the "-devpac" option enabled.

Since doing the restore, I have rebuilt my installation from scratch using the original ADF images of my own disks and had been working on resourcing GenAm to fix this, but hadn't actually tried assembling these things again until I was in a position to fix things.

Having just tried now, everything I tried assembled fine, I can only assume I had a rogue setting in my restored GenAm.opts file which resulted in the error message and the assembly failing. When I get a chance, I'll see if this fixes the other errors I was getting and I'll also restore my QB backup and compare the configurations to see what is different.

[kamelito]

I got an email from Andy today it is Atari ST related but might interest some of you.
https://github.com/amp64/Atari_ST

[Thomas Richter]

Just to add to this, thanks to this information, SegTracker now also allows reading and storing debug information such that my usual collection of debugging tools can pick up function names and line number information.