Menu
▾
▴
[Nasm-users] Re: [linux-nasm-users] Assembler bugs
|
From: Frank K. <fbk...@co...> - 2005-03-27 15:08:06
|
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
|
