nasm-users

[Frank K. <fbk...@co...>]

jeff wrote:
> 
> Hello all,

Hiya Jeff,

> My list of things to avoid in nasm now has
> two items.  I've wasted a few days tracking
> these down, so hopefully this will save everyone
> else some time:

Thanks for the feedback! Since much of this isn't limited to
Linux, I'll cc this to a couple other lists, if you don't
mind. (if you do mind - too late, sorry :)

> 
>  1.  Any line ending with "\" will convert the
>      next line into a commennt.

This is not correct, AFAIK. Ending a line with a backslash
causes Nasm to append the following line to the line ending
in a backslash, as if it were written all on one line.

>      This becomes a
>      serious problem if the "\" is at the end
>      of a comment and the next line is a assembler
>      instruction.

It "continues" the line. If you don't intend to "continue"
the comment, don't end the line in a backslash!

>      No warning is given and the
>      instruction is ignored.  The problem here is
>      knowing that the problem happened.  The GDB
>      debugger often shows source and everything looks
>      ok.

I'll have to look into that. My "quickie" test is puzzling
me - ";this is a comment\" is *not* being continued, and the
following line *is* being assembled. This is not the
intended behavior - it's the way *I'd* like to see it work,
but the "team" want's it to work like gcc, which apparently
*does* continue the comment. 

Ah! I, see! I was apparently using a "modified" version...
an attempt to "fix" the behavior you don't like :) Using
straight 0.98.39, it *does* continue the comment to the next
line. Okay... In gdb, a "listing" of the file shows what we
wrote, a "disassembly" (or stepping through the program)
shows the next line *not* assembled. This is potentially
confusing, I guess, but I think it's "correct"... How would
you like to see it work?

I can send you my "fix", but it's logically incorrect - "mov
al, ';'\" will treat the ';' as if it were a comment
character, and *not continue the line (not that there's any
logical reason to continue this particular line...) Well,
it's short, here it is:

--- /home/fbk/nasm/preproc.c	Mon Jan 17 00:24:02 2005
+++ /home/fbk/nasmtemp/preproc.c	Wed Feb  2 20:07:30 2005
@@ -663,14 +663,16 @@
         if (p > buffer && p[-1] == '\n') {
             /* Convert backslash-CRLF line continuation
sequences into
                nothing at all (for DOS and Windows) */
-            if (((p - 2) > buffer) && (p[-3] == '\\') &&
(p[-2] == '\r')) {
+            if (((p - 2) > buffer) && (p[-3] == '\\') &&
(p[-2] == '\r')
+                && 0 == strchr(q, ':')) {
                 p -= 3;
                 *p = 0;
                 continued_count++;
             }
             /* Also convert backslash-LF line continuation
sequences into
                nothing at all (for Unix) */
-            else if (((p - 1) > buffer) && (p[-2] == '\\'))
{
+            else if (((p - 1) > buffer) && (p[-2] == '\\')
+                     && 0 == strchr(q, ';')) {
                 p -= 2;
                 *p = 0;
                 continued_count++;


I *strongly* suggest that you *don't* use this code! It's
too simple-minded to work correctly! (but it *did* work on
my "quickie test")

>      Another aspect of this problem is that editors
>      with assembler syntax higlighting show the
>      comment line as an istruction.  This adds a
>      confusing twist.

This is a problem for authors of syntax-highlighting editors
to solve. Yes, it's "new syntax" for Nasm, and it *does*
break some existing code - which we *try* to avoid - but it
was a much-requested, and badly-needed (IMO) feature.

>  2.  The warning "ld can not find entry symbol" may
>      be triggered by adding the -O2 flag to nasm.

It does a lot worse than that! It emits totally bogus code.
This is a bug in Nasm - you *should* get a "phase error" (or
"not enough passes") message and quit. This'll be fixed for
0.98.40, probably.

>      Once again this problem is easy to fix, just
>      change the -O flag to -O1 or omit it.

Well, you could do that... but the better solution would be
to use a *larger* parameter to the "-O" switch - I use
"-O999", when I use the "-O" switch at all.

>      The problem
>      is that you can be working away and the problem
>      pops up.  What caused it?

A change in the way the parameter to the "-O" switch is
processed. In the original optimizer code, "-O2" and "-O3"
were special-cased to give you 10 and 15 (maximum) extra
"optimizing" passes. "-O4" gave you only 4 passes... The
Nasm development team, in its infinite wisdom, decided that
this inconsistancy, and the special-casing of "-O2" and
"-O3", should be removed in favor of "the number you give is
the number you get" ("-O1" is still "special"). If this
produced the proper error-message in the case of too few
passes, it wouldn't be too bad.

Personally, I don't see any reason to limit the maximum
number of passes at all - it isn't faster, Nasm quits when
it's done. I'd give 999 passes - or 999999 (some code can
take a lot of passes to resolve!) - if any number >=2 was
given. In the case of code that simply *won't* resolve, this
would make Nasm appear to hang... or you'd wait a *long*
time for an error message. Since it doesn't work that way,
we just have to use a good big number.

I haven't looked at your latest code, Jeff, but with an
earlier version, I thought I saw something weird... the
executable was bigger with "-O999" than with no "-O" switch.
(IIRC, I had to add a couple "near" specifiers to get it to
assemble without at least "-O1"). I've gotta re-check, and
see if that was really happening. This would be *very*
puzzling, if true, but it's a different issue than the lack
of an error - and incorrect code - if "-O2" isn't enough (I
think...).

> Both of these problems were found by going back to nasm
> version 22 which has been rock solid here.

Suit yourself. It has come to my attention that the latest
"asmutils" insists on "pure" 0.98 - I haven't been able to
find out why - perhaps to avoid 0.98.37, which had broken
elf output. Code is available clear back to 0.91, for those
who don't like "new fangled gadgets". But there's a *reason*
for all those releases - a number of serious bugs have been
found and fixed! If you're assembling code that doesn't
trigger these bugs, you don't need to upgrade, but I assure
you, they're there waitin' for ya!

Best,
Frank