Feature request: debuggable macros

[doynax]

On Mon, May 12, 2008 at 4:46 AM, anonymous coward
<nasm64developer at users.sf.net> wrote:
> > I'm currently working on a project where the assembler code consists almost
> > entirely of macros. [...]
>
> Can you provide sample code?

Sure, though it's a bit straightforward. Lets say you have the
following stupid little float-to-int converter and are trying to
assemble it, with debugging information, for Visual Studio:

	bits 32

	%macro doit 0
	sub esp,4
	fld dword [esp+8]
	fistp dword [esp]
	pop eax
	ret
	%endmacro

	global _ftoi
_ftoi: ;int __cdecl _ftoi(float)
	doit

Now, trying to run this through the debugger does result in it
stepping once line per instruction, as it should, but with the cursor
staying put at the macro invocation point rather than moving through
the macro's instructions as would be more useful. I suppose the ideal
solution would be to fake a call stack somehow for each macro level
but I doubt that's possible or worth the effort.
Perhaps for certain tiny utility macros, say a multiple push sequence,
the current scheme might be more useful. But for anything less
foolproof than that you pretty much want to see what's going on.

In my case my assembler code primarily consists of a set of software
blitters where various types of graphics operation are combined with
various ways of fetching source pixels to create the functions, plus
there are some specializations for different instruction sets and
such. This results in two or three levels of macros where the entire
functions are generated entirely from macros rendering the debugging
information virtually useless. And with the current mess of
instruction sets to support I rather think I'm not alone with this
kind of setup..

As for the error issue lets say you forgot to specify the size of the
store then what you get from the assembler is the proper "invalid size
for operand 1" message but reported for the line of the macro
invocation. Reasonable behavior here would be to dump the entire macro
heirachy when something goes wrong as most assemblers tend to do.
Anyway as you can imagine this leads to a lot of manual binary
searching whenever something goes wrong, which is both time consuming
and error prone (e.g. forgetting to comment something back in again).