nasm-users — Discussion and help for Nasm users.

[Nasm-users] Working with pointers

[Littlefield, T. <ty...@ty...>]

hello all,
I have a quick question.
I have the following:
section .data
ptr dd 0
array times 100 db 0

Now, when I want to assign array to p, I can't mov it--how can I assign 
the pointer to point there? Last, is there a way to get the type of 
processor?
(32-64), as that will make a difference on the code in some places?

-- 

Thanks,
Ty

Re: [Nasm-users] learning asm

[H. P. A. <hp...@zy...>]

On 10/13/2010 02:01 AM, Frank Kotler wrote:
> 
> Jakob's answered that, too (Thanks, Jakob!). Perhaps an example...
> 
>      18 00000000 55                      push ebp
>      19 00000001 89E5                    mov ebp, esp
>      20 00000003 83EC08                  sub esp, 8
>      21
>      22
>      23
>      24 00000006 89D874020407            foo
> 
> The leftmost column is just line numbers in the source file. Next is the
> address.

Actually right now they're just line numbers, which don't match up with
the source file... fixing that would be a good thing.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [Nasm-users] nasm intermittently fails to assemble a file

[Jakob B. <jb...@wi...>]

On 13-10-2010 06:15, anonymous coward wrote:
>> The .asm file is generated by the makefile just before invoking nasm
>> ...
>> Yeah, but in this case it IS the exact same .asm file and nasm binary
>> that failed a few seconds or minutes before, which makes me wonder
>> what could induce nasm to behave differently.
>
> Does your build system ensure serialization between the Perl script
> that generates the .asm file and the invocation of the NASM binary?
>

Yep, that was it!  Now I have to figure out how to make the upstream
build system (not my own), ensure the perl run does not exit until it
is done writing the file.  This is a classic non-parallel makefile
system, so this really shouldn't have happened, but it did.

> Another possibility is bad buffering, i.e. NASM invoked immediately
> may see a partial .asm file (not from disk, but a memory buffer), but
> NASM invoked a little later may see the proper .asm file (from disk).
>
Equally possible, given the circumstances above.

> You could try to replace the NASM binary with e.g. cat, to show the
> content of the .asm file. Though... if that doesn't show a partial .asm
> file, then you might need to "work your way backwards" by building a
> custom NASM binary that prints out every input line. (Of course that
> might change buffering enough to hide/avoid the problem.)

I tried that (with a custom clone of cat, since cat is not a standard
binary on Windows and a ported cat would barf at the other commandline
args anyway), and it showed that the .asm file was either empty or
missing when "nasm.exe" started.

Thanks for the help

Jakob Bohm

Re: [Nasm-users] learning asm

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

Tyler Littlefield wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello all,

Hi Tyler,

> I'm looking for a few things, and maybe someone can help me out some.
> I've been toying with asm for a while, but I'd really like to dive in.
> One of my problems is proper information on what things like enter and
> leave do, etc. Is there a good reference somewhere?

Jakob's given you probably the best answer - Intel and/or AMD manuals.
Since I was used to it, I "rescued" the instruction set reference
chapter from the old Nasm Manual:

http://home.myfairpoint.net/fbkotler/nasmdocr.html

This has the advantage of being in Nasm syntax, but doesn't include any
information on effect of instructions on flags (among other
shortcomings). Another alternative:

http://ref.x86asm.net/

If what you need is more information on where, how, and why you'd use
enter, leave, etc. maybe a tutorial would be more help:

http://www.drpaulcarter.com/pcasm/

> I'm also curious of the output of a .lst file, and how it's organized:
> There don't seem to be column headers, so I'm having issues figuring out
> what's what with my reader.

Jakob's answered that, too (Thanks, Jakob!). Perhaps an example...

     18 00000000 55                      push ebp
     19 00000001 89E5                    mov ebp, esp
     20 00000003 83EC08                  sub esp, 8
     21
     22
     23
     24 00000006 89D874020407            foo

The leftmost column is just line numbers in the source file. Next is the
address. When the linker's had its way with it, these addresses will be
relocated - this is what Nasm knows at the time the list file is
generated. Next is the byte(s) that Nasm will emit, and then the source
code. The last line is what you get from "%macro foo 0.nolist" - the
macro doesn't get expanded into "source code" at all. Without the
".nolist", the output is a little "too" cluttered (depending on your
taste). Some more discussion on the forum:

http://forum.nasm.us/index.php?topic=906.0

> Also, are there some good nasm samples out there to play with? Iseen a
> text editor, but that might just confuse me, then confuse me again.

Nothing worse than being confused twice! Unless it's being confused
three times... or more. :)

There are a few dos examples on my web page - not very good ones.
Starting off with dos isn't a bad idea (IMO), but you don't want to
waste too much time with it. There's a selection of examples here:

http://codewiki.wikispaces.com/

Not all for Nasm, but you can find 'em. The !YAHOO! win32-nasm-users
group has got a bunch of examples in the "files" section. For those who
don't want to join a Yahoo group, I liberated them and put them on
SourceForge:

<http://sourceforge.net/projects/nasm/files/example%20code/yahoowin/yahoowin.zip/download>

It's a bit of a "code bomb" - you'll have to unzip individual
directories and sort out what's what. Probably easier to join the group
(though that won't help all that much). Needs to be "indexed"! Nasm
versions of the code from Iczelion's Windows tutorials are in there, if
that's what you're looking for. The Tutorials themselves are here:

http://win32assembly.online.fr/

Pretty old, but a good start in Windows, if that's what you're after.

There are examples in the forum...

http://forum.nasm.us/index.php?board=3.0

... but fairly "random".

If you're not finding anything at the right "level" - somewhere between
"hello world" and the text editor - maybe make some suggestions and
we'll see if we can work up something...

Best,
Frank

Re: [Nasm-users] nasm intermittently fails to assemble a file

[anonymous c. <nas...@us...>]

> The .asm file is generated by the makefile just before invoking nasm
> ...
> Yeah, but in this case it IS the exact same .asm file and nasm binary
> that failed a few seconds or minutes before, which makes me wonder
> what could induce nasm to behave differently.

Does your build system ensure serialization between the Perl script
that generates the .asm file and the invocation of the NASM binary?

Another possibility is bad buffering, i.e. NASM invoked immediately
may see a partial .asm file (not from disk, but a memory buffer), but
NASM invoked a little later may see the proper .asm file (from disk).

You could try to replace the NASM binary with e.g. cat, to show the
content of the .asm file. Though... if that doesn't show a partial .asm
file, then you might need to "work your way backwards" by building a
custom NASM binary that prints out every input line. (Of course that
might change buffering enough to hide/avoid the problem.)

Re: [Nasm-users] nasm intermittently fails to assemble a file

[Jakob B. <jb...@wi...>]

On 13-10-2010 01:40, Frank Kotler wrote:
> Jakob Bohm wrote:
>
>  > P.P.S
>  > I am new to this list, hope my question is OK.
>
> No. Too difficult. Take it away! :)
>
> Seriously, welcome aboard, Jakob! I've cleared your "moderation" flag,
> so you should be able to post without delay, from now on. [hint: "reply
> all" to copy the list - just "reply" will reply only to me]
>
>> Hi, I am having a strange problem with nasm, which has me somewhat
>> baffled:
>
> Me, too! Someone more knowledgeable is probably going to have to bail me
> out on this...
>
>> When building a specific project (Openssl 1.0.0a for Win64-amd64),
>> nasm 2.09.02 (and 2.08.02 and 2.08.01 too) fails to assemble one of the
>> files (x86_64_cpuid.asm) when run on one build machine, but not the
>> other.
>
> So... what differs? Same build of Nasm? Same Perl?
>

I tried copying over the same nasm.exe, same result

Different perl though, but the asm file looks fine, see also below

> I downloaded the source, but I can't find the file in question (or even
> the tmp32 directory). I deduce that this is built from
> crypto/x86_64cpuid.pl... perhaps with the assistance of
> crypto/perlasm/x86_64-xlate.pl and/or x86nasm.pl? Closest thing I see on
> my system (*old* Linux) after doing "make" is x86cpuid.s, which doesn't
> help. Can you give me a "dummies' guide" to creating this file? (or post
> it?)
>

The .asm file is generated by the makefile just before invoking nasm, 
this is upstreams buildsystem, so I have limited control over what it 
does or how.

On a higher level, the sequence of commands is

...\openssl-1.0.0a>perl Configure VC-WIN64A --prefix=C:\somedir
...\openssl-1.0.0a>call ms\do_win64a
...\openssl-1.0.0a>nmake -f ms\nt.mak install


> Better yet(?), can you confirm that the .asm files on the "good" machine
> and the "bad" machine are identical?
I haven't checked, but the file looks normal in a text editor after the
failure, see also below.

>
>> Strangely, manually running the same nasm command with the same values
>> of all environment variables on the computer where it just failed,
>> produces the correct output, but running the build script always fails
>> on that same computer.
>
> That makes it sound like the problem is external to Nasm, no?
>

Yeah, but in this case it IS the exact same .asm file and nasm binary 
that failed a few seconds or minutes before, which makes me wonder what
could induce nasm to behave differently.

>> When nasm fails in that buildscript on that machine, it randomly
>> chooses between two different failure modes:
>
> I don't think Nasm includes a random number generator, so this too
> points to something other than Nasm - although I can't imagine what.
>
Uninitialized memory, process id, system load could be factors if one of 
those might trigger a latent bug.
>> A (most frequent): nasm reports success (no messages and 0 exit code),
>> but the generated .obj file is empty (not 0-byte), containing no code,
>> data or symbols, just a valid .obj file header (This obviously leads
>> to a later linker error).
>>
>> B (less frequent): nasm aborts claiming that all the local symbols
>> are undefined.
>
> Very strange, no matter what's doing it!!!
>
>> On the other build machine, nasm just works as expected for the same
>> files.
>
> Yeah, that's what it's "supposed" to do... :)
>
>> What could be causing this
>
> Dunno.
>
>> and how do I work around this?
>
> If we figure out the first question, we might be able to figure out this
> one. I suppose "don't use that machine" isn't an option...
>
>> P.S.
>> The machine in question is an automated build server which has no
>> trouble building millions of other lines of code (none of them with
>> nasm though). It runs Win2003 server (i386), cross compiling for
>> multiple target architectures (including x86_64).
>
> I'm paranoid enough to think that MS might introduce something that
> would cause random bugs in Nasm. Not paranoid enough to think it's very
> likely, though. :)
>
> So we've got a 32-bit Nasm executable, assembling for "-f win64". That
> "shouldn't" be a problem...
>
>> P.P.S
>> I am new to this list, hope my question is OK.
>
> Sure. I'm delighted to have a message I can approve (mostly, my job on
> this list is rejecting spam). I'm looking forward to a question I can
> actually answer!
>
>> P.P.P.S
>> The error messages when failing in mode B are:
>>
>> nasm -f win64 -DNEAR -Ox -g -o tmp32\x86_64cpuid.obj
>> tmp32\x86_64cpuid.asm
>> (above is one long line wrapped for e-mail)
>
> I can tell you that "-g" is being silently ignored. Shouldn't be a
> problem. You may want to leave it in, to be ready if/when we *do* add
> debug-info to the win32/win64 output formats.
>
Again upstream build system
>> tmp32\x86_64cpuid.asm:5: error: symbol `OPENSSL_cpuid_setup' undefined
>
> [snip more-of-same presumably from the same cause...]
>
>> (The symbols in question are defined on lines before they are used, the
>> errors report the lines where they are used).
>
> Right. Defined as "extern" in the case of "OPENSSL_cpuid_setup" - just
> labels for the rest of 'em?
>
Yep
> But other times, no errors but a "naked" header, right? Exact same .asm
> file, or a new Perl output?
Fresh run of perl each time starting from an empty dir, unpacking source
and running the upstream build system from a batch file.
>
> Damn! I can't imagine what this could be, Jakob! I'm inclined to think
> "not a Nasm problem", but I'm not absolutely certain.
>
> Anyone else (perhaps with Windows experience) got any ideas?
>
> In any case, thanks for the feedback!
>
You're welcome...

Re: [Nasm-users] learning asm

[Jakob B. <jb...@wi...>]

On 13-10-2010 01:47, Tyler Littlefield wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello all,
> I'm looking for a few things, and maybe someone can help me out some.
> I've been toying with asm for a while, but I'd really like to dive in.
> One of my problems is proper information on what things like enter and
> leave do, etc. Is there a good reference somewhere?
The canonical reference that most of us use is to go to for example

<http://www.intel.com/p/en_US/products/server/processor/xeon5000/technical-documents#13>

and download the bunch of .pdf files whose names start with "Intel 64 
and IA-32 Architectures...", especially volume 2A and 2B.  For a few 
details, you may want to also grab the similar documents from AMD to
check the differences.

These contain detailed descriptions of each instruction, what it does,
what can go wrong etc. etc.  The style and layout has been the same 
since the 8086 manual in the late 1970s.

These come in new versions every 1 or 2 years to include the latest new
features.

> I'm also curious of the output of a .lst file, and how it's organized:
> There don't seem to be column headers, so I'm having issues figuring out
> what's what with my reader.

The format of listing files has mostly been the same since the mainframe 
days:  First column is the memory address where the code goes
(relative to where it ends up after nasm has finished), next column is
the actual instruction or data bytes that go at that address, and 
finally there is the source code for those bytes.

Various flag characters in the first two columns indicate such 
variations as if the bytes will have their values changed according to 
where this or some other code is loaded, if this is actual code/data or 
just a structure layout or other definition for use elsewhere etc.

> Also, are there some good nasm samples out there to play with? Iseen a
> text editor, but that might just confuse me, then confuse me again.
>
Sorry, I don't know what nasm-format samples are available.

[Nasm-users] learning asm

[Tyler L. <ty...@ty...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all,
I'm looking for a few things, and maybe someone can help me out some.
I've been toying with asm for a while, but I'd really like to dive in.
One of my problems is proper information on what things like enter and
leave do, etc. Is there a good reference somewhere?
I'm also curious of the output of a .lst file, and how it's organized:
There don't seem to be column headers, so I'm having issues figuring out
what's what with my reader.
Also, are there some good nasm samples out there to play with? Iseen a
text editor, but that might just confuse me, then confuse me again.

- -- 
Thanks,
Tyler Littlefield
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMtPOqAAoJELDPyrppriJP0EsH/A6D51h8OmLTBtmM6AHMG+ej
A7yKHn7GvjPqxqdxGzekJ0vZzN5reri/P2gY+D+7DyC3MTFNMqkAjKiNTcNutdy3
UtJEVvm3Nc4nT6skbDQr1BjCOX9vX2XF4/Tid7Ss26QRIv3sJlr+aFPzAMCgnCDQ
DO390LYqdasVmlQKyafAVASNZqwTnurCYTkcD4aoXMUYtrc+9j0wrEYtrVi2C0ma
9haac+C3+nAjFHtkWSaIOdSceE8XgAK7lsxUvNhdxcylVxUprqTnYzXl+XPQr3YG
Ff1R0i+zu9PF8mIN3GD27u7zPb4mbCwGAHv/KJO8PX5QgyaBIawwnmPOIzoULsQ=
=mlRw
-----END PGP SIGNATURE-----

Re: [Nasm-users] nasm intermittently fails to assemble a file

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

Jakob Bohm wrote:

 > P.P.S
 > I am new to this list, hope my question is OK.

No. Too difficult. Take it away! :)

Seriously, welcome aboard, Jakob! I've cleared your "moderation" flag, 
so you should be able to post without delay, from now on. [hint: "reply 
all" to copy the list - just "reply" will reply only to me]

> Hi, I am having a strange problem with nasm, which has me somewhat
> baffled:

Me, too! Someone more knowledgeable is probably going to have to bail me 
out on this...

> When building a specific project (Openssl 1.0.0a for Win64-amd64),
> nasm 2.09.02 (and 2.08.02 and 2.08.01 too) fails to assemble one of the
> files (x86_64_cpuid.asm) when run on one build machine, but not the
> other.

So... what differs? Same build of Nasm? Same Perl?

I downloaded the source, but I can't find the file in question (or even 
the tmp32 directory). I deduce that this is built from 
crypto/x86_64cpuid.pl... perhaps with the assistance of 
crypto/perlasm/x86_64-xlate.pl and/or x86nasm.pl? Closest thing I see on 
my system (*old* Linux) after doing "make" is x86cpuid.s, which doesn't 
help. Can you give me a "dummies' guide" to creating this file? (or post 
it?)

Better yet(?), can you confirm that the .asm files on the "good" machine 
and the "bad" machine are identical?

> Strangely, manually running the same nasm command with the same values
> of all environment variables on the computer where it just failed,
> produces the correct output, but running the build script always fails
> on that same computer.

That makes it sound like the problem is external to Nasm, no?

> When nasm fails in that buildscript on that machine, it randomly
> chooses between two different failure modes:

I don't think Nasm includes a random number generator, so this too 
points to something other than Nasm - although I can't imagine what.

> A (most frequent): nasm reports success (no messages and 0 exit code),
> but the generated .obj file is empty (not 0-byte), containing no code,
> data or symbols, just a valid .obj file header (This obviously leads
> to a later linker error).
> 
> B (less frequent): nasm aborts claiming that all the local symbols
> are undefined.

Very strange, no matter what's doing it!!!

> On the other build machine, nasm just works as expected for the same
> files.

Yeah, that's what it's "supposed" to do... :)

> What could be causing this

Dunno.

> and how do I work around this?

If we figure out the first question, we might be able to figure out this 
one. I suppose "don't use that machine" isn't an option...

> P.S.
> The machine in question is an automated build server which has no
> trouble building millions of other lines of code (none of them with
> nasm though).  It runs Win2003 server (i386), cross compiling for
> multiple target architectures (including x86_64).

I'm paranoid enough to think that MS might introduce something that 
would cause random bugs in Nasm. Not paranoid enough to think it's very 
likely, though. :)

So we've got a 32-bit Nasm executable, assembling for "-f win64". That 
"shouldn't" be a problem...

> P.P.S
> I am new to this list, hope my question is OK.

Sure. I'm delighted to have a message I can approve (mostly, my job on 
this list is rejecting spam). I'm looking forward to a question I can 
actually answer!

> P.P.P.S
> The error messages when failing in mode B are:
> 
> 	nasm -f win64 -DNEAR -Ox -g -o tmp32\x86_64cpuid.obj
>                                                   tmp32\x86_64cpuid.asm
> (above is one long line wrapped for e-mail)

I can tell you that "-g" is being silently ignored. Shouldn't be a 
problem. You may want to leave it in, to be ready if/when we *do* add 
debug-info to the win32/win64 output formats.

> tmp32\x86_64cpuid.asm:5: error: symbol `OPENSSL_cpuid_setup' undefined

[snip more-of-same presumably from the same cause...]

> (The symbols in question are defined on lines before they are used, the
> errors report the lines where they are used).

Right. Defined as "extern" in the case of "OPENSSL_cpuid_setup" - just 
labels for the rest of 'em?

But other times, no errors but a "naked" header, right? Exact same .asm 
file, or a new Perl output?

Damn! I can't imagine what this could be, Jakob! I'm inclined to think 
"not a Nasm problem", but I'm not absolutely certain.

Anyone else (perhaps with Windows experience) got any ideas?

In any case, thanks for the feedback!

Best,
Frank

[Nasm-users] nasm intermittently fails to assemble a file

[Jakob B. <jb...@wi...>]

Hi, I am having a strange problem with nasm, which has me somewhat
baffled:

When building a specific project (Openssl 1.0.0a for Win64-amd64),
nasm 2.09.02 (and 2.08.02 and 2.08.01 too) fails to assemble one of the
files (x86_64_cpuid.asm) when run on one build machine, but not the
other.

Strangely, manually running the same nasm command with the same values
of all environment variables on the computer where it just failed,
produces the correct output, but running the build script always fails
on that same computer.

When nasm fails in that buildscript on that machine, it randomly
chooses between two different failure modes:

A (most frequent): nasm reports success (no messages and 0 exit code),
but the generated .obj file is empty (not 0-byte), containing no code,
data or symbols, just a valid .obj file header (This obviously leads
to a later linker error).

B (less frequent): nasm aborts claiming that all the local symbols
are undefined.

On the other build machine, nasm just works as expected for the same
files.

What could be causing this and how do I work around this?

P.S.
The machine in question is an automated build server which has no
trouble building millions of other lines of code (none of them with
nasm though).  It runs Win2003 server (i386), cross compiling for
multiple target architectures (including x86_64).

P.P.S
I am new to this list, hope my question is OK.

P.P.P.S
The error messages when failing in mode B are:

	nasm -f win64 -DNEAR -Ox -g -o tmp32\x86_64cpuid.obj
                                                  tmp32\x86_64cpuid.asm
(above is one long line wrapped for e-mail)
tmp32\x86_64cpuid.asm:5: error: symbol `OPENSSL_cpuid_setup' undefined
tmp32\x86_64cpuid.asm:18: error: symbol `L$spin' undefined
tmp32\x86_64cpuid.asm:54: error: symbol `L$intel' undefined
tmp32\x86_64cpuid.asm:65: error: symbol `L$intel' undefined
tmp32\x86_64cpuid.asm:71: error: symbol `L$intel' undefined
tmp32\x86_64cpuid.asm:81: error: symbol `L$done' undefined
tmp32\x86_64cpuid.asm:84: error: symbol `L$done' undefined
tmp32\x86_64cpuid.asm:86: error: symbol `L$done' undefined
tmp32\x86_64cpuid.asm:91: error: symbol `L$nocacheinfo' undefined
tmp32\x86_64cpuid.asm:104: error: symbol `L$notintel' undefined
tmp32\x86_64cpuid.asm:108: error: symbol `L$notintel' undefined
tmp32\x86_64cpuid.asm:112: error: symbol `L$done' undefined
tmp32\x86_64cpuid.asm:115: error: symbol `L$done' undefined
tmp32\x86_64cpuid.asm:120: error: symbol `L$done' undefined
tmp32\x86_64cpuid.asm:136: error: symbol `L$ot' undefined
tmp32\x86_64cpuid.asm:138: error: symbol `L$ret' undefined
tmp32\x86_64cpuid.asm:143: error: symbol `L$ittle' undefined
tmp32\x86_64cpuid.asm:149: error: symbol `L$aligned' undefined
tmp32\x86_64cpuid.asm:153: error: symbol `L$ot' undefined
tmp32\x86_64cpuid.asm:159: error: symbol `L$aligned' undefined
tmp32\x86_64cpuid.asm:161: error: symbol `L$ittle' undefined
NMAKE : fatal error U1077: '!NASM208DIR!\nasm.EXE' : return code '0x1'

(The symbols in question are defined on lines before they are used, the
errors report the lines where they are used).

Re: [Nasm-users] Unable to generate IA64 object file

[anonymous c. <nas...@us...>]

> According to section 6.8 of the NASM Manual, IA64 is supported.
>
> 6.8 CPU: Defining CPU Dependencies
>
> The CPU directive restricts assembly to those instructions which are available on the specified CPU.
>
> Options are:
>
>    * CPU IA64 IA64 CPU (in x86 mode) instruction set

This means that NASM supports the JMPE instruction,
which is specific to IA-64 incarnations of x86: it triggers
a return from x86 to IA-64 mode.

How IA-64 processors execute x86 code -- the first ones
could do it in hardware while the current ones use binary
translation -- is beyond the scope of NASM.

> Do I need to use a newer version of nasm?

No, a newer version won't make a difference.

See my other reply, to your original message.

Re: [Nasm-users] Unable to generate IA64 object file

[anonymous c. <nas...@us...>]

> Does anyone see what is wrong with this.  This is using version 2.04.
>
>         COMPILING: ../../examples/cpuidExample/cpuid.asm
>
> nasm -I../../src/ -I../../examples/ -f elf64 -DCPU=IA64 -o
> objs/examples/cpuidExample/cpuid.o ../../examples/cpuidExample/cpuid.asm

You successfully assembled x86 source code into
an ELF object file for x86-64. Looks like NASM did
work as expected.

>         LINKING: target/examples/cpuidExample
>
> /usr/lib/gcc/ia64-suse-linux/4.1.2/../../../../ia64-suse-linux/bin/ld:
> warning: i386:x86-64 architecture of input file
> `objs/examples/cpuidExample/cpuid.o' is incompatible with ia64-elf64 output

Your IA-64 linker refused to link the aforementioned
x86-64 object file into an IA-64 executable.

You should use an x86 or x86-64 linker instead and
create a 32- or 64-bit x86 binary. How you'd run that
binary on your IA-64 system is beyond the scope of
NASM. The original Itanium processors had support
for it in hardware, but the current ones rely on binary
translation.

In short: not a NASM problem.

Re: [Nasm-users] Unable to generate IA64 object file

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

Youngman, James wrote:
> According to section 6.8 of the NASM Manual, IA64 is supported.
> 
> 6.8 CPU: Defining CPU Dependencies
> 
> The CPU directive restricts assembly to those instructions which are available on the specified CPU.
> 
> Options are:
> 
>     * CPU IA64 IA64 CPU (in x86 mode) instruction set

Yeah? Okay, we just need to persuade your ld to accept the linkable 
object format then...

> Do I need to use a newer version of nasm?

I doubt if it'll help, but you probably want to anyway. The truth is 
that a lot of bugs crept in with the 2.x series. We're up to 2.10rc1 - 
all the "known" bugs have been fixed... Might as well try out the latest 
"snapshot"...

http://www.nasm.us/

Does "objdump -i" give any hints what you'd need to tell ld? (or gcc?)

Best,
Frank

Re: [Nasm-users] Unable to generate IA64 object file

[Youngman, J. <jam...@hp...>]

According to section 6.8 of the NASM Manual, IA64 is supported.

6.8 CPU: Defining CPU Dependencies

The CPU directive restricts assembly to those instructions which are available on the specified CPU.

Options are:

    * CPU IA64 IA64 CPU (in x86 mode) instruction set

Do I need to use a newer version of nasm?

Thanks
Jim

-----Original Message-----
From: Frank Kotler [mailto:fbk...@zy...] 
Sent: Tuesday, October 05, 2010 5:05 PM
To: Youngman, James
Cc: nas...@li...
Subject: Re: [Nasm-users] Unable to generate IA64 object file

Youngman, James wrote:
> Does anyone see what is wrong with this.  This is using version 2.04.
> 
>  
> 
>         COMPILING: ../../examples/cpuidExample/cpuid.asm
> 
> nasm -I../../src/ -I../../examples/ -f elf64 -DCPU=IA64 -o 
> objs/examples/cpuidExample/cpuid.o ../../examples/cpuidExample/cpuid.asm
> 
>         LINKING: target/examples/cpuidExample
> 
> /usr/lib/gcc/ia64-suse-linux/4.1.2/../../../../ia64-suse-linux/bin/ld: 
> warning: i386:x86-64 architecture of input file 
> `objs/examples/cpuidExample/cpuid.o' is incompatible with ia64-elf64 output

Hi Jim,

Thanks for the message I could approve! I don't know much about 64-bit 
code, but doesn't "IA64" refer to Itanium? Nasm won't do Itanium, only 
x86-64. I fear you won't be able to use it. :(

On my antique 32-bit system, I can list targets accepted by ld with 
"objdump -i" (go figure!). Possible your ld will handle x86-64 if asked 
properly?

Best,
Frank

Re: [Nasm-users] Unable to generate IA64 object file

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

Youngman, James wrote:
> Does anyone see what is wrong with this.  This is using version 2.04.
> 
>  
> 
>         COMPILING: ../../examples/cpuidExample/cpuid.asm
> 
> nasm -I../../src/ -I../../examples/ -f elf64 -DCPU=IA64 -o 
> objs/examples/cpuidExample/cpuid.o ../../examples/cpuidExample/cpuid.asm
> 
>         LINKING: target/examples/cpuidExample
> 
> /usr/lib/gcc/ia64-suse-linux/4.1.2/../../../../ia64-suse-linux/bin/ld: 
> warning: i386:x86-64 architecture of input file 
> `objs/examples/cpuidExample/cpuid.o' is incompatible with ia64-elf64 output

Hi Jim,

Thanks for the message I could approve! I don't know much about 64-bit 
code, but doesn't "IA64" refer to Itanium? Nasm won't do Itanium, only 
x86-64. I fear you won't be able to use it. :(

On my antique 32-bit system, I can list targets accepted by ld with 
"objdump -i" (go figure!). Possible your ld will handle x86-64 if asked 
properly?

Best,
Frank

[Nasm-users] Unable to generate IA64 object file

[Youngman, J. <jam...@hp...>]

Does anyone see what is wrong with this.  This is using version 2.04.

        COMPILING: ../../examples/cpuidExample/cpuid.asm
nasm -I../../src/ -I../../examples/ -f elf64 -DCPU=IA64 -o objs/examples/cpuidExample/cpuid.o ../../examples/cpuidExample/cpuid.asm
        LINKING: target/examples/cpuidExample
/usr/lib/gcc/ia64-suse-linux/4.1.2/../../../../ia64-suse-linux/bin/ld: warning: i386:x86-64 architecture of input file `objs/examples/cpuidExample/cpuid.o' is incompatible with ia64-elf64 output

Thanks
Jim

[Nasm-users] Feature request (ELF)

[bastl <ba...@fr...>]

Hello
It would be nice to have dynamic linking support in ELF systems.
E.g to have the COMMON directive for all symbols and not only for variables.
Some keywords:
- elf shared libraries,
- linux LKMs (thread at http://forum.nasm.us/index.php?topic=841.0),
- OOP and runtime linking (modules).

bastl

[Nasm-users] Feature request (ELF)

[S.Beck <seb...@fr...>]

Hello
It would be nice to have dynamic linking support in ELF systems.
E.g to have the COMMON directive for all symbols and not only for variables.
Some keywords:
- elf shared libraries,
- linux LKMs (thread at http://forum.nasm.us/index.php?topic=841.0),
- OOP and runtime linking (modules).

bastl

Re: [Nasm-users] From Gas to Nasm

[Paul P. <ppr...@gm...>]

> Best,
> Frank
>
>
Ya know, I had this 4k page response all written up (kidding), stating what
problems I was having, etc., but instead of wasting your time, I just wanna
say thanks!  There aren't very many people out their willing to donate their
time to help the scrubs like myself.  After visiting the forum you
mentioned, I can see you are very active in helping others.

You rock Frank!

Thanks!
-- 
Paul
__________________

:(){ :|:& };:

Re: [Nasm-users] From Gas to Nasm

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

Paul Procacci wrote:
> Hello All,
> 
> I'm a newbie at Nasm and trying to get my chops wet.  In fact my asm 
> isn't stellar at all, but trying to learn it as a hobbyist.  I've 
> decided to start off with a very simple subroutine, attempting to get 
> that working first but I'm running into lots of problems.  I was able to 
> write my function in Gnu's Assembler which worked fine, however I don't 
> like it's syntax, hence the reason for attempting to write it in Nasm 
> which I like better.  The c library function I am attempting to mimic is 
> bzero.  In short it's  "void bzero(char *addr, unsigned int len)".  I 
> would have thought this would be quite easy but alas.
> 
> ###############################
> section .text
> global bzero
>           ; void bzero(char *s, unsigned int len);
> 
> bzero:
>         enter 0, 0
> .loop:
>         cmp [esp + 12], 0                        ; If length is zero
>         je .done                                       ;     we are done
>         mov eax, [ebp + 8]                     ; Move address of pointer 
> into eax
>         mov [eax], 0                                ; 0 out location 
> referenced in eax
>         add [ebp + 8], 1                          ; add 1 to the address
>         sub [ebp + 12],  1                        ; subtract 1 from 
> value of length
>         jp .loop                                         ; continue with 
> loop
> .done:
>         leave
>         ret
> ###############################
> 
> I've tried prefixing the some of the addresses with the keyword 'byte' 
> but that didn't help much either.  (Ex:  "add byte [ebp + 8], 1")

Hi Paul,

That's the right trick, although you'd want "dword" in that particular 
case. Gas, of course, has got the size built into the mnemonic - 'b' for 
"byte", 'w' for "word", and 'l' for "long", which Nasm calls "dword" 
(just so it won't be too easy). In many cases, Nasm can determine the 
size by the register specified... sometimes we just have to tell it.

When we poke the zero into memory, we want just a byte. (optimization - 
do several bytes at once) But incrementing the pointer we'd need "add 
dword [ebp + 8], 1". Suppose our starting address was 0x8049200, and we 
did "add byte [ebp + 8], 1"... it would work up to 0x80492FF, but 
instead of going to 0x8049300, just the low byte would "roll over" - 
0x8049200! Our routine would "work" much of the time, but would 
mysteriously fail if we crossed a 256 byte boundary. A good kind of bug 
to avoid!!!

;-------------------------
section .text
global bzero
           ; void bzero(char *s, unsigned int len);

bzero:
         enter 0, 0
.loop:
         cmp dword [esp + 12], 0         ; If length is zero
         je .done                        ;     we are done
         mov eax, [ebp + 8]         ; Move address of pointer into eax
         mov byte [eax], 0          ; 0 out location referenced in eax
         add dword [ebp + 8], 1     ; add 1 to the address
         sub dword [ebp + 12], 1    ; subtract 1 from value of length
         jmp .loop                  ; continue with loop
.done:
         leave
         ret
;---------------------------

Did you mean to use esp in that first reference to "length"? It'll work 
(but generates a longer instruction - oddity in the way instructions are 
encoded). I'd stick to ebp, throughout. Also, "jp" is "jump if parity 
even" - pretty sure you meant "jmp".

This could perhaps be improved... After getting the address in eax, we 
don't need to update the parameter we were passed and reload eax each 
time through the loop. We could just load eax once, and increment it 
with "inc eax" (short) or "add eax, 1" (faster) or even "lea eax, [eax + 
1]" (executes in the Address Generation Unit instead of the Arithmetic 
Logic Unit - potential speedup keeping them both occupied). We could 
also load the "length" into a register and manipulate the register 
instead of the memory location. If the memory location is "in cache" 
(which the stack would usually be), it's only a little faster to use a 
register than memory, but...

I mentioned the possibility of zeroing more than one byte at once. What 
you'd do is check the low bits of the address to see it it's dword (or 
more) aligned - if not, do a byte at a time until it is - then do 4 (or 
8? or more?) bytes at a time - do any odd bytes at the end one at a 
time. Worth it if the length is long...

But get it working, first. http://www.agner.org when you're ready for 
optimization. :)

> Also, I'd like to include the Gas example that did work that I'm trying 
> to convert into Nasm style syntax.
> ###############################
> bzero:
>         pushl   %ebp
>         movl    %esp, %ebp  
> .loop:
>         cmpl    $0, 12(%ebp)
>         je      .done
>         movl    8(%ebp), %eax
>         movb    $0, (%eax)
>         addl    $1, 8(%ebp) 
>         subl    $1, 12(%ebp)
>         jmp .loop
> .done:
>        popl    %ebp
>         ret
> ###############################

I find that Gas (AT&T) syntax "bothers" me a lot less as time goes on... 
(my taste-buds must be getting dull :) I still prefer Nasm!

> If this is the wrong list, I apologize in advance and would like an 
> appropriate pointer to the correct list.

This is the right list! I was specifically asked to create this list to 
keep this kind of question off the developer's list. As you can see, it 
doesn't get much traffic! Thanks for posting a message I can approve! 
(you won't have to wait for "moderation" after the first message) (you 
want to hit "reply all"! Just "reply" replies only to the poster)

Another good place to ask questions (or share observations) is the shiny 
new Nasm forum:

http://forum.nasm.us/

This replaces the SF forum, which had been "improved" beyond usability.

Best,
Frank

[Nasm-users] From Gas to Nasm

[Paul P. <ppr...@gm...>]

Hello All,

I'm a newbie at Nasm and trying to get my chops wet.  In fact my asm isn't
stellar at all, but trying to learn it as a hobbyist.  I've decided to start
off with a very simple subroutine, attempting to get that working first but
I'm running into lots of problems.  I was able to write my function in Gnu's
Assembler which worked fine, however I don't like it's syntax, hence the
reason for attempting to write it in Nasm which I like better.  The c
library function I am attempting to mimic is bzero.  In short it's  "void
bzero(char *addr, unsigned int len)".  I would have thought this would be
quite easy but alas.

###############################
section .text
global bzero
          ; void bzero(char *s, unsigned int len);

bzero:
        enter 0, 0
.loop:
        cmp [esp + 12], 0                        ; If length is zero
        je .done                                       ;     we are done
        mov eax, [ebp + 8]                     ; Move address of pointer
into eax
        mov [eax], 0                                ; 0 out location
referenced in eax
        add [ebp + 8], 1                          ; add 1 to the address
        sub [ebp + 12],  1                        ; subtract 1 from value of
length
        jp .loop                                         ; continue with
loop
.done:
        leave
        ret
###############################

I've tried prefixing the some of the addresses with the keyword 'byte' but
that didn't help much either.  (Ex:  "add byte [ebp + 8], 1")

Also, I'd like to include the Gas example that did work that I'm trying to
convert into Nasm style syntax.
###############################
bzero:
        pushl   %ebp
        movl    %esp, %ebp
.loop:
        cmpl    $0, 12(%ebp)
        je      .done
        movl    8(%ebp), %eax
        movb    $0, (%eax)
        addl    $1, 8(%ebp)
        subl    $1, 12(%ebp)
        jmp .loop
.done:
       popl    %ebp
        ret
###############################

If this is the wrong list, I apologize in advance and would like an
appropriate pointer to the correct list.

Thanks,
-- 
Paul
__________________

:(){ :|:& };:

Re: [Nasm-users] can't write argv[0] on stdout - solved

[H. P. A. <hp...@zy...>]

On 08/19/2009 10:56 AM, Holger Hanrath wrote:
> 
> from the AMD64 Abi:
> 
> "3. The number of the syscall has to be passed in register %rax."
> 

Correct.  Loading a value into eax clears the upper 32 bits of rax, however.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [Nasm-users] can't write argv[0] on stdout - solved

[H. P. A. <hp...@zy...>]

On 08/19/2009 11:43 AM, Frank Kotler wrote:
> H. Peter Anvin wrote:
>> On 08/19/2009 10:11 AM, Frank Kotler wrote:
>>> Or even:
>>>
>>> push write
>>> pop rax
>>>
>>> Smaller, if that's the goal, but slower (I think), and it doesn't do 
>>> much for "readability", IMO.
>>>
>> 	mov eax,...
>>
>> ... is even smaller (5 bytes.)
> 
> I should have specified the "-Ox" switch, or "push byte write".
> 

Ah yes, that does work for values <= 127.  It's really slow, though.

	-hpa

Re: [Nasm-users] can't write argv[0] on stdout - solved

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

H. Peter Anvin wrote:
> On 08/19/2009 10:11 AM, Frank Kotler wrote:
>> Or even:
>>
>> push write
>> pop rax
>>
>> Smaller, if that's the goal, but slower (I think), and it doesn't do 
>> much for "readability", IMO.
>>
> 
> 	mov eax,...
> 
> ... is even smaller (5 bytes.)

I should have specified the "-Ox" switch, or "push byte write".

Best,
Frank

Re: [Nasm-users] can't write argv[0] on stdout - solved

[H. P. A. <hp...@zy...>]

On 08/19/2009 10:11 AM, Frank Kotler wrote:
> 
> Or even:
> 
> push write
> pop rax
> 
> Smaller, if that's the goal, but slower (I think), and it doesn't do 
> much for "readability", IMO.
> 

	mov eax,...

... is even smaller (5 bytes.)

	-hpa