Re: Dredging up bugs...

Frank Kotler wrote:
> "H. Peter Anvin" wrote:
>
>
> > What *does* make it work, however, is to change FILENAME_MAX and
> > FILENAME_MAX_LG2 from equ's to %defines.  If I assemble with -O0, it
> > complains that these are used before they are defined, which is incorrect.
>
>
> FILENAME_MAX    equ (1 << FILENAME_MAX)   ; Max mangled filename size
>
> Can this be right??? Changing this to "1 << FILENAME_MAX_LG2" (wild
> guess, but it seems more logical) - leaving both as "equ", and with the
> default "-O0" - shuts Nasm up on this point. Now I'm getting an error
> that "pc_getline" is undefined in "parseconfig.inc" (line 275).

Right; that's clearly a bug in the source.  NASM should puke at this 
point, why it doesn't with the optimizer on is a problem.

> Changing *this* equ to a "%define" seems to get me by that. Still need
> to define "HEXDATE" and "DATESTR" on the command line. Now "-O0" won't
> work - "short jump out of range". "-O1" give a "bootsector overflow".
> "-O2" gives a (legitimate?) "phase error". "-O3" (and greater) seems
> okay. With the "-O" switch, I can change back to an "equ" in
> "parseconfig.inc"...
>
> "make" still doesn't do it, but I think it's barfing on another file...
> "cpp0: Too many arguments" from "syslinux.c"? At this point, I'm lost...

For me, it works fine with "make" and the corrected equ; no funnies with 
"make".  What version of "make" are you using?

> > In my case it emits an output file, but I have no way of knowing if it
> > is any good.
>
> An output file, but no list file??? That *is* weird! Damn! I'm not able
> to get a list file either, even though the assembly seems to be going
> okay! Hmmm... with "1 << FILENAME_MAX_LG2", all seems okay - getting a
> list file. With the original "1 << FILENAME_MAX", no list file, and the
> optimizer *does* appear to run for as many passes as you allow. Well,
> that looks like an "infinite loop" to me, anyway. I claim it's "pilot
> error", but Nasm could be coping with it better... I dunno...

It is pilot error, but coping with programmer's errors is IMO a key 
piece of functionality for a development tool.  The fact that it 
produced an output file and did exit(0); is a *major* flaw; barfing is 
bad (doesn't help find the error), but producing bad output and not 
altering make with the exit code is just a total no-no.

> P.S. On another topic entirely... should I apply Andreas' "slang"
> patch???

Makes sense to me.

        -hpa


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/