Re: NASM 0.98.39 vs. NASM 2.03.01 disassembly

"Alexei A. Frounze" <alexfrunews@xxxxxxxxx> ha scritto nel messaggio
news:2d7b1027-9f13-4602-b810-b9b0813070c2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

I was only involved in two things, which I thought were bad ('cause I
needed them to work:):
1. include paths for INCBIN and the direction of the path traversal.
I've been credited for this somewhere in the doc.
2. broken symbolic debug information for Turbo Debugger. I don't
remember if this actually got fixed or reverted to what it was. The
problem AFAIR was that some of the state was saved in variables
declared as static and some NASM's functions were relying on those to
keep the state between the calls. Somebody very smartly decided to
"fix" these ugly static variables and just dropped static effectively
turning the variables into local ones. The wrong fix broke the
symbolic info.

For the problem of use the Borland Debugger

nasmw -fobj file.asm
bcc32 -v file.obj

and in the file.asm there should be
"
section _DATA use32 public class=DATA
global f
global _main

section _TEXT use32 public class=CODE
f:
ret

...start: ; here should start with ..start:
_main: ; it seems the linker search _main
ret
"

all symbols that the debugger has to see, must be global.
If the "f" is not global it is not seen.

I sent a bunch of messages on this to nasm-devel at lists... and
exchanged some info with Frank. The messages were from July 2003 and
their subject line contained:
a) Nasm + Borland ( was Once more time - outbin.c (fwd))
b) NASM's Borland Debug Info Output
I think I wasn't credited for this and that's because probably it
didn't get fixed...
Can somebody look this up in the old mail and then in the NASM source?

Alex



.