Devpac Debug Issue with multiple files

[sandruzzo]

I've split my code into many files, but when I debug my code that isnt' into main file, MONAM won't show me proprerly my code. There is a way to show my debug code correctly when I debut it? Here a PIC:I'm debugging a code which is into another file. Monam show me raw data instead codes' label(red circle)

[phx]

Not many replys, maybe because you gave not enough information.

What do you expect MonAm to show "properly" and "correctly"? The symbols (InitLinkedList) are obviously there. Are you missing the correct source text line in the bottom window to be displayed? Don't know which "labels" you are missing, though.

And how did you split your code over multiple files? Did you assemble them separately to generate multiple object files? With HCLN or LINE debug hunks?
Or did you just include multiple source files into a single source file?

[sandruzzo]

Originally Posted by phx

Not many replys, maybe because you gave not enough information.

What do you expect MonAm to show "properly" and "correctly"? The symbols (InitLinkedList) are obviously there. Are you missing the correct source text line in the bottom window to be displayed? Don't know which "labels" you are missing, though.

And how did you split your code over multiple files? Did you assemble them separately to generate multiple object files? With HCLN or LINE debug hunks?
Or did you just include multiple source files into a single source file?

I include all the files, into single source with "inclue /name.asm". I dont' use any hunks.

What it's missided are simbols from source code: I see offsets instead "labels name". I'll show you: Into red circle you'll see what I would like to see into Monam, instead numbers, like I see now( previous pic)

[IMG][/IMG]

[Thomas Richter]

Originally Posted by sandruzzo

I include all the files, into single source with "inclue /name.asm".

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

Originally Posted by sandruzzo

I dont' use any hunks.

(-; Hardly. You use at least one, namely that where your code is in.

Originally Posted by sandruzzo

What it's missided are simbols from source code: I see offsets instead "labels name".

That cannot work. The debugger can hardly know what type of structure a0 is pointing to, so it cannot relate the offsets to any particular symbol. An offset of 4 from a0 could mean a lot, e.g. it could also mean ln_Pred (from exec/nodes.i).

[sandruzzo]

Originally Posted by Thomas Richter

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

Since I',m not really good a this stuff, How I can do it very efficiently with DevPac?

[modrobert]

From the Devpac manual.

The Debug Symbols cycle gadget lets you choose which symbols to
include in the executable. You normally include symbols in a file so that you
can see them when using the debugger. The choice is:

None - Outputs no symbols
All - Outputs all symbols
Exports - When using linkable code only exports are output

Choosing Line Debug includes information about the code addresses
corresponding to the line numbers in your program for use with the MonAm
debugger. Two formats are available: Standard which uses LINE debug
hunks that are compatible with the CodeProbe debugger that is supplied with
SAS/C. Compressed uses HCLN hunks which need approximately one
quarter of the space of LINE hunks but are not understood by CodeProbe.
Beware that even using the compressed format increases the size of your
program substantially. MonAm understands both formats.

I uploaded the manual to the zone.

[sandruzzo]

@modrobert

Thanks a lot

[phx]

Originally Posted by sandruzzo

Since I',m not really good a this stuff, How I can do it very efficiently with DevPac?

There is an option in the Devpac GUI to select "Linkable" output format. Otherwise use the command line tool (GenAm) and the

-l

option:

genam -l -otest.o test.asm

Then link the object files with any AmigaDOS linker of your choice (alink, blink, slink, vlink, phxlnk).

[sandruzzo]

@phx

Thanks

[StingRay]

Originally Posted by Thomas Richter

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

Not necessarily. ASM-One (and its many derivates) cache include files so they are only increasing the build time the very first time they are accessed.

[Photon]

Including source files is of course also necessary for any code that isn't dead (finished) in any language.

It's good practice to move parts of code (source or compiled) into separate files. Even parts of code you think aren't quite dead (finished) yet. This creates structure, and a basic Separation of Concerns, in any language.

Originally Posted by Thomas Richter

That cannot work. The debugger can hardly know what type of structure a0 is pointing to, so it cannot relate the offsets to any particular symbol.

You can absolutely write a debug symbols exporter that relates a value in the code to an exported symbol. The debugger must support it.

[Thomas Richter]

Originally Posted by StingRay

Not necessarily. ASM-One (and its many derivates) cache include files so they are only increasing the build time the very first time they are accessed.

In that case, exactly once. Thus, there is no gain. The trouble is, if you change a file, you need to reassemble everything again, instead of just link the binaries of the modules.

[Thomas Richter]

Originally Posted by Photon

You can absolutely write a debug symbols exporter that relates a value in the code to an exported symbol. The debugger must support it.

Except if that symbol is a relative symbol to an unknown base. What should a debugger do with a

 move.l d0,4(a0)

Is the 4 an "ln_Pred" or a "mlh_Tail"? Exactly - it cannot possibly know.

[sandruzzo]

Bit when All Is into main file, It works ad expected. All sources symbols, labels and so forth are well dislayed

[mcgeezer]

Originally Posted by sandruzzo

Bit when All Is into main file, It works ad expected. All sources symbols, labels and so forth are well dislayed

Do you really need the source files to hand when debugging your code? uaedbg along with MonAm really does help massively with debugging.

What sort of tool chain are you running? Having all of your code in one file is unworkable - I have a general rule where I try to keep my source files all under 1000 lines of assembler and I hold all data vars in separate files.

i.e.
main.asm -> main.dat
sprite.asm -> sprite.dat

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.

[Photon]

Originally Posted by Thomas Richter

Except if that symbol is a relative symbol to an unknown base. What should a debugger do with a

 move.l d0,4(a0)

Is the 4 an "ln_Pred" or a "mlh_Tail"? Exactly - it cannot possibly know.

It can know by the offset to the value in the file. A debugger can also know variables that are put on the stack in all languages. On the stack there are no offsets at all. How much information you can provide depends only and completely on how the debug exporter is written and how well an internal or external debugger supports the debug format.

Compiling and linking finished code is only important when the code is -- finished. I don't know why you're somehow against including finished or unfinished code as source. The half second of compile time is for the author to decide, and certainly not a bad habit, rather the opposite.

[Galahad/FLT]

I use Devpac exclusively, and have never had a problem with multiple files.

I tend to have a main code file, and then include files for generic stuff like killing AmigaDOS and restoring, theres no need to have these well used routines cluttering up the main code file because I no longer need to fiddle with them, they work and are reliable, so they are separate and get included at assembly.

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.

Its how a lot of programmers used Devpac because its typically very reliable with multiple files, I only ever found Master Devpac buggy but then I don't think it was an official release.

[Thomas Richter]

Originally Posted by Photon

It can know by the offset to the value in the file.

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.

[sandruzzo]

Thomas,

I Never had this kind of problems with visual studio. Its Just a Little bit annoying, not a big del.

[meynaf]

Originally Posted by Thomas Richter

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.

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".
Then the debugger sees the 4, looks for its address (not its value) in the table, and, if found, displays the name instead.
I don't know if it's actually done this way, but it is how i would do it.