Re: Alexei fixes for NASM w/Borland TD

On Aug 22, 7:17 pm, Frank Kotler <fbkot...@xxxxxxxxxxx> wrote:
Like the careless butcher, I've gotten a little behind in my work.
Lemmee jump into this now...

Rod Pemberton wrote:
"Alexei A. Frounze" <alexfrun...@xxxxxxxxx> wrote in message
news:3e119cb0-eed6-4ca9-bb9e-9c736444fbb1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Aug 22, 1:23 am, "Rod Pemberton" <do_not_h...@xxxxxxxxxxxxx> wrote:
"Alexei A. Frounze" <alexfrun...@xxxxxxxxx> wrote in
messagenews:2d7b1027-9f13-4602-b810-b9b0813070c2@xxxxxxxxxxxxxxxxxxxxxxxxxxx
m...
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.

I remember and appreciate it! I think they've added "%incbin" and
tweaked "incbin". I *hope* your code still works!

2. broken symbolic debug information for Turbo Debugger. I don't
remember if this actually got fixed or reverted to what it was.

As best I can recall, you had it improved - it was working for me. I
think there may have been more you wanted to do. I kinda "dropped the
ball" and wasn't much help, as I recall.

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.
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...

You're listed in AUTHORS for "incbin" paths and "bugswatting"...

Can somebody look this up in the old mail
[NASM-devel mail links]

Thanks, Rod!

Yep those. I still have the e-mails from those threads and all
attachments. So, if somebody wants to fix a real bug or confirm it
already being fixed, I may share those if needed.

I may be able to dig up what you sent me... haven't, yet...

and then in the NASM source?
I'll leave that to someone more familiar...
Same here. I just kept using the old NASM without that bug.

There's always that option. :)

I think they're miffed at the moment...

Naw, not me, anyway. I'm sorry you couldn't get your bug fixed.
Consensus on the development team seems to be that it's okay as-is.
Don't feel bad, Agner Fog just got a bug-report closed as "not a bug", too!

You might've been better off with
another thread.

This one's okay... Thanks for changing the name! If anyone wants to get
serious about fixing it, maybe better to take it up in "official
channels" (yes, SF can be a royal pain), but as you observe, developers
hang out here, too. (*not* all of 'em - Ed Beroset was offering help, IIRC)

Anyway, from the NASM-devel archives (including some other related posts),
this is how I'd summarize the issue:

1) "static" keyword eliminated on variables lnfname and lineno for out()
in assemble.c

Apparently... but they're back...

2) non-static variables and/or if(src_get()) fail to preserve/restore
variables needed for debugging info
3) switching back to static variables from non-static caused invalid
free()

That "nasm_free" didn't make much sense whether it was static or
automatic, did it? If you'd used "Nasm_strdup" to copy it, maybe...



4) you posted a "patch" which copied the non-static variables to static
variables as a work around
5) your "patch" also appears to generate other Borland debug info

NASM 2.03.01 code in assemble.c for out() uses "static" keyword for lineno
and lnfname. NASM 2.03.01 code in assemble.c for out()'s if(src_get())
[correctly] doesn't call nasm_free() when lnfname is static.

I.e., From what I read in the NASM-devel archives, it appears to code has
been fixed, assuming the invalid free() was found. Since I don't
have Borland TD available and don't know how to use it anyway, what is the
problem Alexei?

1) credit due
2) still not working properly
3) missing extra debug info your code provided

Rod Pemberton

Current code (20080821) looks like (assemble.c):

static void out(int64_t offset, int32_t segto, const void *data,
enum out_type type, uint64_t size,
int32_t segment, int32_t wrt)
{
static int32_t lineno = 0; /* static!!! */
static char *lnfname = NULL;
uint8_t p[8];

if (type == OUT_ADDRESS && segment == NO_SEG && wrt == NO_SEG) {
/*
* This is a non-relocated address, and we're going to
* convert it into RAWDATA format.
*/
uint8_t *q = p;

if (size > 8) {
errfunc(ERR_PANIC, "OUT_ADDRESS with size > 8");
return;
}

WRITEADDR(q, *(int64_t *)data, size);
data = p;
type = OUT_RAWDATA;
}

list->output(offset, data, type, size);

/*
* this call to src_get determines when we call the
* debug-format-specific "linenum" function
* it updates lineno and lnfname to the current values
* returning 0 if "same as last time", -2 if lnfname
* changed, and the amount by which lineno changed,
* if it did. thus, these variables must be static
*/

if (src_get(&lineno, &lnfname)) {
outfmt->current_dfmt->linenum(lnfname, lineno, segto);
}

outfmt->output(segto, data, type, size, segment, wrt);

}

So the "static" is back in, and we don't attempt to free it... But I
can't test it, either. I *can* look at dumps of the .obj file, but don't
really know what to look for. If you want to get back into it (Alexei or
anybody) we can take another shot at it.

Best,
Frank

Seems like it works OK now. Except for one little thing.
msg db "hello world!", 13, 10, "$"
is displayed in TD as byte[4] if the object file is produced with NASM
and as byte[12] if produced with TASM.

TDUMP has this record for msg:
NASM:
000123 COMENT Purge: Yes, List: No , Class: 227 (0E3h)
0000: 1F 00 04 00 1A 08 ......

TASM:
000154 COMENT Purge: Yes, List: No , Class: 227 (0E3h)
0000: 1F 00 0C 00 1A 08 ......

I indicated this back in 2003.

Alex
.

Relevant Pages