Best debugger for KS3.1?

[copse]

I'm trying to debug a disassembled program under WinUAE using workbench on KS3.1. However, it appears to be unstable. It has some argc (d0)/argv (a0) handling which chokes when AsmOne gives it an argc of 0 under its debugger. Now I can rewrite this code to work around AsmOne's lackings, but it is rather a chore to do so.

Is there a decent Amiga-based debugger/assembler to use? I like the AsmOne debugging experience, but it is rather limited and unstable. There must be something better.

[Leffmann]

BDebug: http://aminet.net/package/dev/asm/BarflyDisk2_00

[copse]

Originally Posted by Leffmann

BDebug: http://aminet.net/package/dev/asm/BarflyDisk2_00

Thanks for the suggestion.

I just tried to use BAsm to compile my code in order to get the debug information I need in the executable to be debugged. It is not particularly user friendly. Many things are errors to it, which should really be automatically corrected and warned about (and are ignored by the likes of AsmOne for instance). It also warns about unimportant bits and pieces and does not provide a way to disable this. This is most likely responsible for the very slow assembly.

I'll see if I can get some other assembler to provide me with a suitably built executable. But DevPac has bugs which prevent it from doing so, maybe AsmOne can do it but I doubt it.

[pmc]

Originally Posted by copse

But DevPac has bugs which prevent it from doing so

Which version of Devpac are you using?

I use Devpac V3.18 (Genam V3.18, Monam V3.08) - I'd be interested in knowing about bugs if you've found some so that I know about them too.

[Leffmann]

Originally Posted by copse

Thanks for the suggestion.

I just tried to use BAsm to compile my code in order to get the debug information I need in the executable to be debugged. It is not particularly user friendly. Many things are errors to it, which should really be automatically corrected and warned about (and are ignored by the likes of AsmOne for instance). It also warns about unimportant bits and pieces and does not provide a way to disable this. This is most likely responsible for the very slow assembly.

I'll see if I can get some other assembler to provide me with a suitably built executable. But DevPac has bugs which prevent it from doing so, maybe AsmOne can do it but I doubt it.

I think you need to go over some BAsm's options. It's highly configurable, but of course it can't support every syntax notation there is. Not sure why it's running so slow for you, it's actually the fastest assembler I've seen, and for large files it will be orders of magnitude faster than others. It could be all the text output that causes AmigaOS to choke.

I see in your other thread that you're trying to assemble and debug source code output by ReSource. I've used BAsm in the past to assemble several megabytes of code output directly by ReSource, without a single warning or error. Try setting New Syntax, Strict Mnemonics and Assembler: Assem in ReSource's options.

BDebug can debug any plain Amiga executable, so any assembler and linker should do, and if you leave all the symbols in you'll see them in the disassembly while you debug as well.

[musashi5150]

Originally Posted by pmc

I'd be interested in knowing about bugs if you've found some so that I know about them too.

I spent a long time head scratching on one of my WHDLoad slaves. Just for something to try I built it using AsmOne instead of my usual choice of Devpac. Then it crashed no more

At the time I didn't feel like looking what the difference in the produced code actually was... but it's been in the back of my mind since Usually I just assume it's my fault

[copse]

Originally Posted by pmc

Which version of Devpac are you using?

I use Devpac V3.18 (Genam V3.18, Monam V3.08) - I'd be interested in knowing about bugs if you've found some so that I know about them too.

That's the version I tried. The bug I had was that when I loaded in my 2 MB .s file, it clipped it and did not have the full length of the file in the buffer. Also when I searched and replaced all occurrences of some match in the file (before I noticed it was clipped) it appeared to corrupt the file. This may be related to the buffer being filled up.

[pmc]

OK thanks for clarifying.

[copse]

Originally Posted by Leffmann

I think you need to go over some BAsm's options. It's highly configurable, but of course it can't support every syntax notation there is. Not sure why it's running so slow for you, it's actually the fastest assembler I've seen, and for large files it will be orders of magnitude faster than others. It could be all the text output that causes AmigaOS to choke.

Absolutely. It's just putting out page after page of warnings at the moment, and they're all scrolling sedately by. If I output to file, which isn't ideal, but of course better than nothing.. it indeed assembles as fast as AsmPro/AsmOne.

I see in your other thread that you're trying to assemble and debug source code output by ReSource. I've used BAsm in the past to assemble several megabytes of code output directly by ReSource, without a single warning or error. Try setting New Syntax, Strict Mnemonics and Assembler: Assem in ReSource's options.

That's a great tip, thanks!

However, there are two problems I would like to solve.

Error 56: The argumentvalue is larger than the operand width.
bsr.b BlahFunc

And the warning which happens 3094 times. Being able to disable this in Barfly would be fine - but.. I don't see any command line options in the documentation which allow that sort of behaviour change.

Warning: Access to first 64k memoryarea.
pea $30

BDebug can debug any plain Amiga executable, so any assembler and linker should do, and if you leave all the symbols in you'll see them in the disassembly while you debug as well.

At this point after the hand replacement of .b branches, I have a compiled executable that works! Thanks :-) The version which comes out of AsmOne crashed, so this is an immediate step up. Looking forward to debugging it - and I'll add your notes on getting Barfly compatible code to the Resource page on my wiki. If you have any thoughts on the two remaining problems, they'd be appreciated.

[Leffmann]

Originally Posted by copse

However, there are two problems I would like to solve.

Error 56: The argumentvalue is larger than the operand width.
bsr.b BlahFunc

And the warning which happens 3094 times. Being able to disable this in Barfly would be fine - but.. I don't see any command line options in the documentation which allow that sort of behaviour change.

Warning: Access to first 64k memoryarea.
pea $30

No way to fix the first one that I know of, the solution is probably somewhere in ReSource's options since it's a genuine error, but the 64k-warning can be removed with -w4- on the command line.

[copse]

Originally Posted by Leffmann

No way to fix the first one that I know of, the solution is probably somewhere in ReSource's options since it's a genuine error, but the 64k-warning can be removed with -w4- on the command line.

Next problem is getting source to display in BDebug. I've tried with the -s1+ and -sf+ options, no success. I've tried with -sd+, no success. The source window option just isn't enabled in BDebug.

Any ideas?

[Photon]

Haven't used BDebug because I'm happy with AsmOne's built-in one, but I guess you're using an option only BDebug has.

If the source won't assemble or throws errors, it's usually damned hard to patch the errors. In the bsr.b case, the cause is almost certainly that some other instruction between the bsr.b and the outside-8-bit-range destination has the wrong size.

It's almost always better to go back to Resource and make sure the disassembly has been done 100% correctly. I always do that until the source assembles perfectly, yielding a binary or object of the exact same size.

You should enable size specifiers for all sizes in Resource, so you can check "what size Resource thinks" the $30 in pea $30 has. You can also check the length of the instruction, and if it's 3 words you must correct the size to .l.

[copse]

Originally Posted by Photon

Haven't used BDebug because I'm happy with AsmOne's built-in one, but I guess you're using an option only BDebug has.

I love AsmOne's debugging interface, but I can't use it. It starts debugging my program and uses SSP as the SP, rather than USP. Why? I do not know. Is this a WinUAE bug, or is this just how things should be working in the AsmOne debugger? It also does not appear to supply valid DOS A0 and D0 values (maybe this is related to the stack problem), which causes the startup logic to choke as on a DOS startup it expects these to be valid.

Originally Posted by Photon

It's almost always better to go back to Resource and make sure the disassembly has been done 100% correctly. I always do that until the source assembles perfectly, yielding a binary or object of the exact same size.

The executable BAsm produces doesn't guru, but it behaves unreliably past a certain point. The executable AsmOne produces gurus. I'll follow your advice, as it seems like the next step forward.

Edit: Hmm. Turning on New Syntax, Strict Mnemonics and the Size Specifier entries brings the AsmOne executable to the level of the BAsm one. That's a step forward. I've turned on data comments and will see if that helps me work out where things differ.

[copse]

Alright, "basm -w4- -sd+ X.asm" does the trick. Then load as file in Bdebug. My mistake was trying to attach to an existing task and expecting the source window to work there.

[Photon]

Don't know if I read you right, but if your program expects to be started from CLI you need to add a wait for LMB or similar to let you switch to the CLI window before executing the code.

I don't know the ins and outs of the debugger in later versions well enough yet to answer about the SSP, but you might uncheck options like Enab/Permit if they are on. And of course if your resourced code has non-68000 instructions in it you'd not like to use an early version.

[copse]

In order to try and get a reassembled file that matches the original, I've decided the way that requires the least work is to adapt some of my old code. I basically just run a script and get the following rough comparison output (original binary versus AsmOne reassembly).

The number 19, is a hunk index. So only four hunks differ, a data hunk differs in size but not content (padded with zeros) and the three code hunks differ in contents.

19 data differs HUNK_CODE
526b/6800: differ point
5277/6800: differ point
27 data differs HUNK_CODE
702e/8320: differ point
702f/8320: differ point
...
8304/8320: differ point
8305/8320: differ point
33 data differs HUNK_CODE
194/780: differ point
195/780: differ point
...
714/780: differ point
715/780: differ point
34 data and size differs HUNK_DATA
0: 464
1: 1100

The data hunk actually seems correct, just written differently. The point of difference is the ds.l/ds.w data at the end of hunk. The original executable expects the hunk loader to allocate the space implicitly (I assume), and the reassembled AsmOne executable seems to reserve this space in the written hunk data. I'm not sure how to specify that an assembler should follow the "implicit space allocation" behavior.

The code hunks I haven't looked at in too much detail... okay, modified my script to print out the byte differences. Just looked at the first differing hunk, index 19. Turns out I had miscalculated some of the hand entered dynamic values, e.g. IDCMP_GADGETDOWN-IDCMP_MOUSEMOVE.. And that fixes the one bug I know of so far. Excellent!

Barfly seems to generate much larger hunks, so I haven't looked at how it differs at all.

[Wepl]

Originally Posted by copse

The executable BAsm produces doesn't guru, but it behaves unreliably past a certain point. The executable AsmOne produces gurus. I'll follow your advice, as it seems like the next step forward.

You have first reach the point where the executable produced by your resourced source is identical to the original before going any further. Use a binary compare program to check where it differs to find the offsets and check/fix them (I use wcmp from whdload_dev package).

To make modifications to the source you have to make sure that all relative calculated values in the source are disassembled/identified that way. This is the hard part of work. This means all code as code identified, pc-relative stuff, relative tables/jump towers and so on.

In my experience it usually is much more effective and less effort to patch the original executable than to make it reassemble.

[copse]

Originally Posted by Wepl

You have first reach the point where the executable produced by your resourced source is identical to the original before going any further. Use a binary compare program to check where it differs to find the offsets and check/fix them (I use wcmp from whdload_dev package).

To make modifications to the source you have to make sure that all relative calculated values in the source are disassembled/identified that way. This is the hard part of work. This means all code as code identified, pc-relative stuff, relative tables/jump towers and so on.

In my experience it usually is much more effective and less effort to patch the original executable than to make it reassemble.

Ah, I didn't know about wcmp, hence I extended my own existing tool. I'll check it out!

On another note, I am not as interested in reassembling, as I am in being able to debug the reassembled code and get a view on what the code is actually doing (rather than cold-reading in Resource). And thanks to working out the problem I describe in the above post, that now appears to be possible.

[Photon]

Originally Posted by copse

Edit: Hmm. Turning on New Syntax, Strict Mnemonics and the Size Specifier entries brings the AsmOne executable to the level of the BAsm one.

Yes, as long as the size is specified correctly for all instructions including pea $38.w and move.l 4.w,a6 and such, the length of the binary will match the original. (Resource 6 resources the very common move.l 4.w,a6 as move.l 4,a6, which will assemble as a long address without size specifiers. I don't know the exact option name to fix it, but maybe someone can help me out?)

So you can't really blame any assembler for producing the wrong output, if information is lost in binary->source disassembly.

[Wepl]

Originally Posted by Photon

Yes, as long as the size is specified correctly for all instructions including pea $38.w and move.l 4.w,a6 and such, the length of the binary will match the original. (Resource 6 resources the very common move.l 4.w,a6 as move.l 4,a6, which will assemble as a long address without size specifiers. I don't know the exact option name to fix it, but maybe someone can help me out?)

Options 1 - Size specifiers - Abs Word