Debugger support

[SamuraiCrow]

Generate metadata for source-level debugging.

[SamuraiCrow]

While AmigaE may have padded out the size of each opcode to 3 words to allow them to be replaced with a JSR with an absolute address, I propose the debugger should use one NOP after before each E instruction for replacement with an Illegal Trap Vector invocation for breakpoints.

[SamuraiCrow]

ECX already included line debugging so maybe standard STABS debugging with BDebug for AmigaOS 3 and earlier is an option. DWARF debugging would work with GDB on AmigaOS 4 and MorphOS. This would make EDBG unneeded but BDebug is closed source.

[Hypexed]

The EC compiler should only output one NOP for substituting with a trap code as you describe. The only exception I know to this is my custom EC compiler that added three NOPs so a JSR could be substituted in place. And would work on OS4.

[Hypexed]

It would help to include standard STABS support so code lines can be located from crash logs. Another issue is DisElf, made for the job, is buggy and crashes bad on OS4 with a trap. However, I still think EDBG or similar would be needed. As for one thing, GDB has been broken on OS4 for almost ten years, no sign it will be fixed. Another is EDBG is the only E source level debugger I'm aware of. And with my EDBG-OS4 patch the only one that works direct on OS4.

[SamuraiCrow]

@Hypexed Thanks for your input and knowledge. Would you like to join the team?

[Hypexed]

Sure!

[SamuraiCrow]

Welcome!

[Hypexed]

Thanks. :-)

[dmcoles]

i've started looking at this. I have added some small changes to EEC to add the necessary NOP instruction and some changes to EDBG to improve the hunk structure handling to cope with EEC files. Currently I am able to step through EEC compiled executables (68k only) using EDBG in OS 3 and OS 4. It is not possible to view variable contents though

[SamuraiCrow]

Thanks for taking this on!

[dmcoles]

Attached is an updated wip EDBG that should support the LDBG and VDBG debug hunks created by EEC.

It will allow you to debug 68k executables generated with EEC but doesn't understand all the EEC/ECX variable types so is quite limited when viewing variable contents at the moment.

EDBG.zip

[SamuraiCrow]

The EDBG that comes with E-VO 3.6.0 says it will work with ECX so it should work here also. It's 68k only at the moment but this could soon be fixed!

[Hypexed]

So at this point the survivors tend to be ECX, EEC and E-VO. At this point it looks like ECX could be depreciated along with EC. But, are all features covered by EEC and E-VO? I suppose the one redeeming feature of ECX would be PPC support.

[Hypexed]

i've started looking at this. I have added some small changes to EEC to add the necessary NOP instruction and some changes to EDBG to improve the hunk structure handling to cope with EEC files. Currently I am able to step through EEC compiled executables (68k only) using EDBG in OS 3 and OS 4. It is not possible to view variable contents though

I'm interested in how you did this. How you modified EDBG to patch NOPs so it works on OS4. Do you substitute a TRAP or something?

[SamuraiCrow]

So at this point the survivors tend to be ECX, EEC and E-VO. At this point it looks like ECX could be depreciated along with EC. But, are all features covered by EEC and E-VO? I suppose the one redeeming feature of ECX would be PPC support.

EEC is a fork to continue development of ECX. ECX has stalled. If Leif wanted to continue development of ECX, our issue tracker could simply be moved to his. Most of the changes were just getting the sources to build.

[dmcoles]

I'm interested in how you did this. How you modified EDBG to patch NOPs so it works on OS4. Do you substitute a TRAP or something?

Yes it adds 3 NOPs instead of just 1 and uses a JSR instruction instead. Both EVO and EEC can produce debug output with either 1 NOP or 3 so you can use the latest edbg with 68k code compiled with either compiler under OS 3.x and OS 4.x

[Hypexed]

Ah okay I see. Yes checked how it was done. So using the same method I did years ago. :-)