I just had an exasperating asm problem which may be of use or interest
to someone else so here's a writeup.

I have a program of about a dozen source files all of which are in Nasm assembly. When I was restructuring it and moving some functions from one
file to another an error occurred.

One of the modules handles a small 'context stack'. It has a routine
called cs.entry_address which returns the address of an entry on the
stack. It had been OK before but after I moved some code it reported

stack entry 134541369 is inaccessible. Stack size is 20

The stack size is correct but the index it had been asked for is a long
way out of range.

I ran the program in gdb to try to find out where the routine had been
called from but what gdb backtrace reported didn't seem to make any
sense as the routine is not called from the place gdb said it had come
from. Further, gdb said there was stack corruption below the caller's
stack frame.

As another tack I put 'print statements' at each place where
cs.entry_address is called thinking that would show which one it was. Surprisingly, the call came from none of them!

I spent ages reading the code looking for potential causes of stack
corruption and not finding any. But after a lot of fiddling around and
head scratching I finally found that the call was coming from the
following instruction:

call compile_error

The routine name, compile_error, isn't important here - except insofar
as it is most definitely not cs.entry_address...!

For some reason what appeared in the code as a call to compile_error
apparently called cs.entry_address instead.

To cut a long story short the problem ended up being that I had the
following statement

global compile_error

in two source files. I removed it from the one it should not have been
in and bing! The program worked as before. I had evidently left the
global statement behind when moving routines out of that file.

What I think was happening was that the first parameter to compile_error
is the address of a string, and it was that address that
cs.entry_address was treating as an index into the stack and reporting
as out of range.

As far as I can see Nasm could have reported an error. The Nasm manual
says global "must refer to symbols which are defined in the same module
as the GLOBAL directive" and there was no symbol of that name therein.

Also, the file had an extern declaration for the same symbol and
global/extern would seem to me to conflict with each other.

Specifically, which file had which symbol was as follows.

* file c0.nasm had the 'compile_error' label and

global compile_error

* file c0_parse.nasm had no compile_error label and had

extern compile_error
global compile_error

FWIW I would have guessed there would be two causes of reportable error:

1. Symbol declared as global is not present.
2. One source file cannot have extern and global for the same symbol.

Anyway, that's it. Knotty problem. Glad it's fixed. Asm debugging can be
a pain!


--
James Harris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/19/2020 06:46 AM, James Harris wrote:

...

    global compile_error

FWIW I would have guessed there would be two causes of reportable error:

1. Symbol declared as global is not present.
2. One source file cannot have extern and global for the same symbol.

I agree.

For the record, I am considered a "Nasm developer" for some trivial contributions I made a long time ago. I have not been actively involved
in Nasm development for a long time.

If you want to try to get this fixed, there's a "bugzilla" where this
could be reported. Let me know if you have trouble finding it.
Otherwise, thanks for the heads up!

Best,
Frank

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20/12/2020 00:31, Frank Kotler wrote:

On 12/19/2020 06:46 AM, James Harris wrote:

...

     global compile_error

FWIW I would have guessed there would be two causes of reportable error:

1. Symbol declared as global is not present.
2. One source file cannot have extern and global for the same symbol.

I agree.

For the record, I am considered a "Nasm developer" for some trivial contributions I made a long time ago. I have not been actively involved
in Nasm development for a long time.

If you want to try to get this fixed, there's a "bugzilla" where this
could be reported. Let me know if you have trouble finding it.
Otherwise, thanks for the heads up!

I knew I ought to raise a bug report but didn't want to go through the
bother: IME bug reports are either ignored, wrongly marked as
duplicates, get people asking unrelated questions, or I get told to
upgrade and try again etc. :-(

Still, I don't think those bug reports were for Nasm and I know you are
right that it should be reported so I have done so at

https://bugzilla.nasm.us/show_bug.cgi?id=3392729

Even that told me the FORM data had timed out or suchlike and I ended up
with two reports so I had to close one of them as a duplicate! Grr!

Still, it's done. Thanks for confirming that the situation looked like a genuine bug.


--
James Harris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20/12/2020 12:49, James Harris wrote:

...

I knew I ought to raise a bug report but didn't want to go through the bother: IME bug reports are either ...

...

... or I get told to
upgrade and try again etc. :-(

The response this time: "upgrade and try again". :-(


That's despite me using the latest Nasm (2.14) in a current distribution
and despite the Nasm bug tracker asking for reports for 2.14 (and even
earlier, back to 2.13). Yet a report on 2.14 gets greeted with "please
try it on 2.15".

Rant mode: IME reporting bugs is usually a waste of time.


--
James Harris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)