Devpac Debug Issue with multiple files

[Thomas Richter]

Which debug info in the Amiga Hunk format would that then be? You can assign an offset relative to a hunk with a symbol, either 32 or 16 relative. This requires two informations: The PC location where it applies to, and the offset value.

[meynaf]

I don't know. There is no exact standard with debug hunks, it seems Devpac has its own.

[phx]

The question whether including source texts or linking with their object files is mostly personal preference. Both have minor advantages and disadvantages, even with compiling/assembling times excluded.

Source inclusion has the advantage that assemblers see all labels and can theoretically perform more optimizations (e.g. branches).

Object files have the advantage that you don't pollute your name space, except for a few exported symbols.

Personally I prefer object file linking, because it feels less messy. I have a clearly defined interface between object files and can easily exchange them between projects (like my trackdisk.o or ptplayer.o).

Originally Posted by mcgeezer

I don't use linkers, I know I could but with the speed with which vasm assembles code I simply do not see the need for compiling each file as an object and linking it.

Your host PC is much too fast!
Try vasm on an A500...

Originally Posted by Galahad/FLT

Same with other routines, PHX's playroutine is separate, I know how to access it and call it, I don't need it in the main code file.

The ptplayer is actually a good example for name space pollution. The last versions define lots of custom chip and CIA registers in the source, so you will usually have trouble by just including the source instead of linking it.

Its how a lot of programmers used Devpac because its typically very reliable with multiple files

Yes, certainly not much of an issue today. But, regarding the translation speed of Devpac it must have been a real pain on native hardware.

[Photon]

Originally Posted by Thomas Richter

As apparently you seem to know more than I, please demonstrate that with DevPac/MonAm, and please explain me which entries in the Amiga debug hunk format provides this information. I'm talking about symbols created with "rsreset" and "rs.b/rs.w/rs.l". Here is the cruncher: Given a pointer in a register (say, a0), how does the debugger know (upon disassembly) whether a0 points to a "struct Node" or a "struct MinList", and thus select the proper symbol for "4(a0)". I do not know how to do that.

Just as it can send "InitLinkedList" for the offset to $2bfff2 and mark it up as a label, it could send "NodeDescSizeOf" for the offset to $2bfffa here and mark it up as data.l Same for $2c0000 and data.w.

Whether a debugger has implemented it doesn't matter, because you said that "a debugger couldn't know that". This is false. It can.

[phx]

Originally Posted by Photon

Just as it can send "InitLinkedList" for the offset to $2bfff2 and mark it up as a label, it could send "NodeDescSizeOf" for the offset to $2bfffa here and mark it up as data.l Same for $2c0000 and data.w.

That may be possible in theory, but not with HUNK_SYMBOL. It only defines symbol names and their section offset (AKA labels). Or absolute symbol names with their values (AKA equates).

As far as I know there is no debugging format for assembler sources which can do that. The more sophisticated, and undocumented, HUNK_DEBUG blocks are only usable for the C language.

Which means in assembler your best option is to enable LINE or HCLN HUNK_DEBUG blocks and hope the debugger shows your original source text for the current PC.

Whether a debugger has implemented it doesn't matter, because you said that "a debugger couldn't know that". This is false. It can.

In defense for Thomas he never generalized, but said "the debugger" and refered to MonAm.

[Thomas Richter]

Originally Posted by phx

That may be possible in theory, but not with HUNK_SYMBOL. It only defines symbol names and their section offset (AKA labels). Or absolute symbol names with their values (AKA equates).

Exactly, this is precisely the problem. First, there is no hunk for that in the Amiga binary format, and second, even if there would be some private hunk, DevPac does not generate it.

Originally Posted by phx

In defense for Thomas he never generalized, but said "the debugger" and refered to MonAm.

Not only. This is not a MonAm specific problem, it is a restriction of the debug data DevPac (and other assemblers) can generate - and this is again a restriction because you don't have type information in assembler. In C, it can be done (though with private data in the debug hunks) since the compiler can store types of function arguments in some private fields. But assembler doesn't have all that either. So it is a pretty basic problem of the language.



For the records, this is exactly the problem I faced when writing my debugger ("COP"), and the best I could come up are symbols that are relative to some public named node. So you do see members of "struct GfxBase", due to some additional magic around the COP "DDT" files, but for your average assembled or compiled binary, it is simply not possible because there is no database where these symbols could come from, and there is no database either that relates registers to members of structures, and that is because assembler does not have "structures" or "types".

[sparhawk]

Originally Posted by Thomas Richter

but for your average assembled or compiled binary, it is simply not possible because there is no database where these symbols could come from, and there is no database either that relates registers to members of structures, and that is because assembler does not have "structures" or "types".

Theoretically the debugger could provide such information in some cases, but it's probably hard to implement. For well known addresses the debugger would have to keep track of the addresses so it knows which register has a certain base address and then it could apply the appropriate offset label as well.

[Bruce Abbott]

Originally Posted by meynaf

I suppose that when the assembler sees ln_Pred(a0) in the source, it writes offset 4 in the code with info in some table inside the debug hunk indicating that this particular "4" is actually "ln_Pred".

But what if the offset is a combination of different structure offsets, eg. move.l a0,$c+8(a0)?

IMO the 'best' way is to show the source code line. But I want to see the actual machine code too, as it gives me a better idea of what is really happening. Rather than using line debugging I simply flip back to the editor screen and search for the nearest code label. This works in assembler because the source and machine code mostly matches up line for line. It's not so useful in high level languages because a source code line usually expands to several lines of machine code which may not have an obvious relationship to the source.

Originally Posted by Thomas Richter

This is not a MonAm specific problem, it is a restriction of the debug data DevPac (and other assemblers) can generate - and this is again a restriction because you don't have type information in assembler.

Not totally true, there are ways to do it using standard debug hunks. But no Amiga assembler currently does this, so unless you write your own assembler it is not an option in practice.

Bad practise. This increases build time. Use separate source files, assemble separately, then link the object files together.

Not necessarily bad. Which method is best depends on a number of factors.

If you use the DEVPAC editor you have to split up large source code files because it screws up if there are too many lines in a single file. The project I am working on right now has ~35000 lines in the main source code file (over 1 million characters each individually typed!) and a few thousand lines in include files. It takes ~8 seconds to assemble with ProAsm on a 50MHz 030 (Barfly takes ~5 seconds). I doubt that moving those few thousand lines into object modules and linking separately would make it much faster.

I could split up the main source, but changes often have to be made to disparate parts at the same time - which would require editing several files and reassembling and linking them each time. It would also involve more boring typing to add the XREFs and XDEFs, and the result would be a bit less efficient because pc-relative code can't span object modules.

On smaller projects there is even less incentive to create object modules and link them separately because the time saved (if any) is even less.

However in large projects with highly modular code that doesn't change much (eg. an OS) it has advantages, including maintaining the modularity so others can use the object code without worrying about source code compatibility etc. High level languages often have long compile times, which makes a separate linking stage much faster when only a few source code files need to be recompiled.

[Thomas Richter]

Originally Posted by Bruce Abbott

IMO the 'best' way is to show the source code line.

If the debugger can access the source code, yes. That is not always possible.

Originally Posted by Bruce Abbott

Not totally true, there are ways to do it using standard debug hunks.

Sigh. No, there are not. Please, believe me. The Amiga standard debug Hunks don't have means to express types or type information. There is more information in what SAS/C writes as proprietary data into the hunk in its own format, but, again, that is proprietary, and not a "standard" that is documented AFAIK.

Originally Posted by Bruce Abbott

Not necessarily bad. Which method is best depends on a number of factors.

If you use the DEVPAC editor you have to split up large source code files because it screws up if there are too many lines in a single file. The project I am working on right now has ~35000 lines in the main source code file (over 1 million characters each individually typed!) and a few thousand lines in include files. It takes ~8 seconds to assemble with ProAsm on a 50MHz 030 (Barfly takes ~5 seconds). I doubt that moving those few thousand lines into object modules and linking separately would make it much faster.

It depends on whether you want to rebuild the whole thing every time. ViNCed as >60000 lines, and no, it makes no sense to assemble all the sources again just because one of the files changed. Use a makefile for that.

Originally Posted by Bruce Abbott

I could split up the main source, but changes often have to be made to disparate parts at the same time - which would require editing several files and reassembling and linking them each time.

Splitting it would force you to think about clear modules, and responsibilities of the sources. 30000 lines in one file is just... too large. Probably by two magnitudes too large for a single file.

Originally Posted by Bruce Abbott

It would also involve more boring typing to add the XREFs and XDEFs, and the result would be a bit less efficient because pc-relative code can't span object modules.

Since when? ViNCEd is all PC-relative with branches between modules, and of course that works. If the distances get too large, the linker will insert ALVs for you (trampoline code).



Side remark:ARexx is just like that, one big pile of mess, assembled with one file that includes a lot of the other sources, with modules that have just numbers, not telling names. Needless to say, it is incredibly hard to maintain this pile of code. Probably that's Bill's revenge against CBM for not having paid him...

[Photon]

Originally Posted by phx

In defense for Thomas he never generalized

In defense of myself, I would never have dared derail the conversation if Thomas hadn't spoken so categorically. He wrote, "a debugger".

A debugger can show operand symbols like sandruzzo wants. It can be done in three different ways without evaluating them (just as for labels). This debugger doesn't support it.

AsmOne, AsmPro and similar have an integrated debugger that can (run-time) show and evaluate operand symbols.

[Thomas Richter]

Originally Posted by Photon

I AsmOne, AsmPro and similar have an integrated debugger that can (run-time) show and evaluate operand symbols.

As long as the debugger reads Amiga hunk format, it cannot support it. This is not a MonAm restriction, it is a restriction of the hunk format.

[phx]

Originally Posted by Bruce Abbott

Not totally true, there are ways to do it using standard debug hunks.

Agreed. The format of a HUNK_DEBUG block is completely free and you can create any complex debugging structures in them. Nothing is impossible.

But no Amiga assembler currently does this, so unless you write your own assembler it is not an option in practice.

An assembler alone is not enough. Unfortunately you also need a debugger which understands your debug information. Otherwise, if you have such a specification which any debugger can use, please tell me, and I will implement it.

Originally Posted by Photon

AsmOne, AsmPro and similar have an integrated debugger that can (run-time) show and evaluate operand symbols.

I have no experience with AsmOne, but I would guess this can only work because the debugger has all information from the previous assembler run available. Definitely an advantage of an integrated assembler-debugger environment.

[Bruce Abbott]

Originally Posted by Thomas Richter

Splitting it would force you to think about clear modules, and responsibilities of the sources. 30000 lines in one file is just... too large. Probably by two magnitudes too large for a single file.

I like it that way because I only have to open one file and know what I want to work on is in there. In this project I often have to work on various parts at the same time, and since I am doing it on an A1200 connected to a TV I don't have a lot of screen space to show multiple files.

However I am open to different ways of doing things, so I will try splitting it up to see if that works better.

ViNCEd is all PC-relative with branches between modules, and of course that works. If the distances get too large, the linker will insert ALVs for you (trampoline code).

I admit I didn't realize this was possible in assembler (never tried merging sections before). I found out that ProAsm can generate XREFs automatically, which saves a bit of typing (still have to put the XDEFs in by hand of course).

I did a small test using blink and it did indeed add 'trampoline' code, and also relocated pc-relative data references. However it seems I need a better linker because it also tried to trampoline data references - and failed spectacularly.

; -- blink tries to 'trampoline' a pc-relative data reference --

   Section 0,CODE

r000000:
   lea     i00000c(PC),A0  ; <-- supposed to be lea r008018(pc),a0
   bsr     r000012
   rts

   align.l
i00000c:
   jmp     r008018         ; <-- but was 'trampolined' with a jmp!
r000012:
   jmp     r00801a         ; <--- this one is OK

; -- second object file merged here --

w000018:
   ds.b    32768

r008018:                   ; oops! not code!
   dc.w    $1234
r00801a:
   lea     w000018,A0
   rts

   align.l

   end

blink also caused a few enforcer hits during operation, even when not 'stressed'. Not sure that I can trust it.

'Trampolining' branches only works if there is less than 32k between the branch and the end of the section. This means I will have to split my code up into sections with less than 32k of code in them to ensure the 'trampoline' works. Alternatively I could just change long branches into jmps like I do now, which produces tighter and faster code.

Side remark:ARexx is just like that, one big pile of mess, assembled with one file that includes a lot of the other sources, with modules that have just numbers, not telling names. Needless to say, it is incredibly hard to maintain this pile of code. Probably that's Bill's revenge against CBM for not having paid him...

Or perhaps he just prefers to code that way.

Splitting code up into separate object files can also be messy. Some Amiga programs that (I presume) were coded by people unfamiliar with advanced linking techniques have a very large number of hunks, sometimes with only a few bytes or nothing in them. AmigaBASIC has 81 hunks. F18-Interceptor has 185 hunks! The source code for that must be 'interesting'.

[mcgeezer]

Originally Posted by Bruce Abbott

I like it that way because I only have to open one file and know what I want to work on is in there. In this project I often have to work on various parts at the same time, and since I am doing it on an A1200 connected to a TV I don't have a lot of screen space to show multiple files.

Do you find yourself spending more time looking for the code you need to change as opposed to the actual time it takes to modify it?

Each to their own but I suspect you're limiting yourself by using an editor on the A1200, try using modern tools to make development easier and more efficient for yourself.

[meynaf]

Originally Posted by Bruce Abbott

I like it that way because I only have to open one file and know what I want to work on is in there.

You're not alone in that case.
I might add that when doing code refactoring, source splitting just goes in the way.

Originally Posted by Bruce Abbott

blink also caused a few enforcer hits during operation, even when not 'stressed'. Not sure that I can trust it.

I use phxlnk when a linker is necessary. It never failed on me.

Originally Posted by Bruce Abbott

AmigaBASIC has 81 hunks. F18-Interceptor has 185 hunks! The source code for that must be 'interesting'.

Civilization (ECS) has 116 hunks. Seems it has been beaten

Originally Posted by mcgeezer

Each to their own but I suspect you're limiting yourself by using an editor on the A1200, try using modern tools to make development easier and more efficient for yourself.

Modern tools have the option to show whole parts of the source as single line (you know, with these little "+" at the left), so being multi-files is even less useful here.

[Bruce Abbott]

Originally Posted by phx

An assembler alone is not enough. Unfortunately you also need a debugger which understands your debug information.

Yes, I realize that. I was refuting the argument that no debugger (no matter how much it 'understands') can do it because the assembler can't provide it with the required information.

Otherwise, if you have such a specification which any debugger can use, please tell me, and I will implement it.

Many assemblers can generate line debugging info. From there it shouldn't be hard for the debugger to extract the offset names from the source text - if that's what you really want. Personally I prefer to see the actual offsets in the disassembly.

[sparhawk]

Originally Posted by Bruce Abbott

I like it that way because I only have to open one file and know what I want to work on is in there.

Wow! 30000 Lines is quite a lot. Well, you have to live with it, so it's your choice anyway.
I'm writing some stuff for the C128 and when the code reached about 3000 lines, I already found it quite annoying to have everything in one file and having to scroll up and down all the time, so I started to split it. Even with bookmarks it gets tedious to navigate IMO.

[Bruce Abbott]

Originally Posted by mcgeezer

Do you find yourself spending more time looking for the code you need to change as opposed to the actual time it takes to modify it?

Nope. I know the names of all my functions. Only takes a few seconds to type in and search. Use search history buffer to find previous or use jump to automark to toggle between them. With separate files I would have to open each one and be constantly rearranging their windows. Much messier. I only have to push one key in CED to save the source and assemble it. Now I am back on the Workbench screen, so... double-click on the program icon or one click and select debug from toolsmenu to debug it. The program, debugger, and editor are all on their own screens ready to view or hide instantly. Clean, efficient, simple, reliable.

Each to their own but I suspect you're limiting yourself by using an editor on the A1200, try using modern tools to make development easier and more efficient for yourself.

Sure I am limiting myself. But it's not about getting the most productivity - it's about enjoying using my Amiga.

I used a PC to develop software for other retro platforms because doing it on the target machine would have been a pain. But not so the A1200. It's a totally different experience from a modern PC, but not a bad one. I love the way it operates and how it feels - the smooth accurate mouse, the big bold display, the multiple screens and efficient multitasking, the comforting click of the floppy drive, the beautiful lines of the wedge-shaped case etc. Programming my Amiga is really just an excuse to play with the machine I love.

[mcgeezer]

Originally Posted by Bruce Abbott

Nope. I know the names of all my functions. Only takes a few seconds to type in and search. Use search history buffer to find previous or use jump to automark to toggle between them. With separate files I would have to open each one and be constantly rearranging their windows. Much messier. I only have to push one key in CED to save the source and assemble it. Now I am back on the Workbench screen, so... double-click on the program icon or one click and select debug from toolsmenu to debug it. The program, debugger, and editor are all on their own screens ready to view or hide instantly. Clean, efficient, simple, reliable.

This is all fine but i would argue modern tools have the same functionality as far as editing is concerned. For testing and debugging i just have machine configs connected to Shift F11 (Test) & Shift F12 (MonAm Debug), each machine takes around 5 seconds to assemble and run.

Originally Posted by Bruce Abbott

Sure I am limiting myself. But it's not about getting the most productivity - it's about enjoying using my Amiga.

I used a PC to develop software for other retro platforms because doing it on the target machine would have been a pain. But not so the A1200. It's a totally different experience from a modern PC, but not a bad one. I love the way it operates and how it feels - the smooth accurate mouse, the big bold display, the multiple screens and efficient multitasking, the comforting click of the floppy drive, the beautiful lines of the wedge-shaped case etc. Programming my Amiga is really just an excuse to play with the machine I love.

For me it is about getting the most productivity efficiently and as easily as possible.

[Bruce Abbott]

Originally Posted by sparhawk

Wow! 30000 Lines is quite a lot...
I'm writing some stuff for the C128 and when the code reached about 3000 lines, I already found it quite annoying to have everything in one file and having to scroll up and down all the time

Once you get past a few screens it doesn't matter - whether it's 300 lines or 30000 lines you still have to scroll 'all the time' to get where you want to be.

I am usually only scrolling up and down through one function, so it doesn't matter how big the file is (within reason). However not everything is in a single file. Things like startup code, the file requester, and data that doesn't change are kept in separate files that are included in appropriate places. In my USB BASIC for the Aquarius I split the code into 13 separate files for the different functions (USB driver, DOS, disassembler/monitor, windows, AY player etc.).