SLD include files

[stevexyz]

One esemplificative line for the output selected for the SLD of Z80 fasmg file has currently the format:

main.asm|2745|includefile.inc|438|0|18134|T|ld c,2

Where 2745 is the line number of the main.asm file (where the include instruction is) and 438 is the line in includefile.inc of the instruction at address 18134 (and the instruction is ld c,2).

The problem is that when the program is debugged with DeZog, visual studio displays the main file with the include directive line, instead of going into the include file where the real executed instruction is. And this for all the instructions in include files.

How to change this behaviour and display the source file with the real executed instruction line?

Should we avoid to list the reference to the expansion of the include or macro and just report source file (of the macro/include) and line number in the first two fields as below?

includefile.inc|438|||0|18134|T|ld c,2

---

PS: for convenience from the sjasmplus page the fields are defined as:

<source file>|<src line>|<definition file>|<def line>|<page>|<value>|<type>|<data>

<source file> - file name of top-level source emitting the instruction/label/device.

<src line> - line and characters in top-level source file

<definition file> - file name of the source defining the particular instruction (for example where the instruction inside MACRO was originally defined). If empty, the definition-file name is identical to <source file> (common case for single-source projects).

<def line> - zero when there is no extra "definition" of instruction involved. When non-zero, the format is identical to <src line>, but with regard to the file specified in <definition file> field.

[maziac]

"It's not a bug, it's a feature." Just kidding.

Historically the macros have been expanded in list files. In many assemblers it is anyway not reconstructable anymore were they came from.

For sld it would (most probably) be possible. But there are also good reasons not to step into a macro.

E.g. for the ZXNext development I was using the z80asm and defined the next instructions as macros. I wouldn't want to step into each macro to see what is happening inside the macros.

I.e. stepping inside makes only sense for more complicated macros.

One solution could be to step into the macro with "step-into" and step over it with "step-over".

But there are other problems: Currently each address is associated with one file/line AND each line in a file is associated with one address. E.g. if you would try to set a breakpoint in a macro it would fail as there is no associated single address line for it. (A macro could be used several times so there would be many addresses.) As the internal stepping procedure also relies on putting a breakpoint in the next line, stepping would not work anymore.

A workaround for you could be watch the disassembly window (in VARIABLES). It contains the disassembled code and you can use single-step to step through the macro code (although you don't see the sources).

[stevexyz]

Regarding my use case would be good to be able to debug inside the macros, since they contain chunks of the overall code.

Regarding the "other problems" surely the association line->address (and not address->line) is a bit of a limitation, but might be managed in some way taking into consideration that the combination of the two lines (source and definition) is unique, and this might be also one of the reasons to have both specified. As a side effect when setting a breakpoint on a macro line would then require to set multiple breakpoints (one for each address of the pairs associated to it).

As a side note, in my particular use case the problem of multiple addresses for the same line doesn't exist since for me the macros are a way to programmatically (with the power of fasmg) relocate chunks of code in optimal positions.

[maziac]

Yes, for sure it could be done. But the internal structures of DeZog are not made for this. And I don't feel that I will implement this because I know I would have to touch a lot of locations in the SW. And there will be a lot of other restrictions. Just one of them: E.g. in ZEsarUX there is a limit of 100 breakpoints. With a macro that is widely used one could easily get there (just thinking of the nextreg instruction in my code). The problem is: even if this is maybe just a seldom use case, I would have to find a way to deal with it. I.e. there is a big chance of breaking other behavior and that I will spent a lot of hours and in the end it would work only in half of the cases. So, I better leave it as it is. Sorry.

[stevexyz]

Hoping anyway in some future to see the management of the step into macros I can understand that it's not easy and might be done just in case more need will be required. Personally I would leave anyway the current makesld output since seems aligned to specifications. I will create a (easy) postprocessing to move include lines (and macro ones if possible) on the first two columns for now to be able to go and debug into these lines.