I'm trying to learn about assembly with the book "Programming from the ground up". The book covers only 32 bit instructions. Is there a way to run the example codes on 64 bit Ubuntu system? I can't understand the stuff on the man page of the GNU assembler but I heard the -m32 flag should do it. But it's not a recognized option.
How do I get the examples on the book to work with ease?
When your assembler and linker are x86_64 versions, the options to produce i386 (32-bit) output are
as --32
ld -m elf_i386
You don't have to use as and ld just because you're working with assembly code. gcc can be used, and in that case you would use -m32.
gcc -m32 -nostdlib myprog.s -o myprog
From the as man page:
Target i386 options:
[--32|--n32|--64] [-n]
[-march=CPU[+EXTENSION...]] [-mtune=CPU]
I'm not sure if it works, just try --32 or --n32.
(-m32 seems to ge the corresponding gcc flag.)
Creating a 32-bit executable on a 64-bit PC requires that you "warn" the linker that a 32-bit elf file is coming:
$ nasm -f elf -g -F stabs eat.asm
$ ld -o eat eat.o -melf_i386
That's what the melf_i386 directive does: It tells ld that the eat.o file is an elf32 linkable object file. The invocation of NASM is the same as you'd use on a 32-bit PC.
Thanks #Jeff Duntemann
Related
I am trying to follow the exercise in the book PC Assembly by Paul Carter. http://pacman128.github.io/pcasm/
I'm trying to run the program from 1.4 page 23 on Ubuntu 18. The files are all available on the github site above.
Since original code is for 32bit I compile using
nasm -f elf32
for first.asm and asm_io.asm to get the object files. I also compile driver.c
I use the linker from gcc and run
gcc -m32 -o first first.o asm_io.o driver.o
but it keeps giving me a bun of errors like
undefined reference to '_scanf'
undefined reference to '_printf'
(note _printf appears instead of printf because some conversion is done in the file asm_io.asm to maintain compatibility between windows and linux OS's)
I don't know why these errors are appearing. I also try running using linker directly
ld -m elf_i386 -e main -o first -first.o driver.o asm_io.o -I /lib/i386-linux-gnu/ld-linux.so.2
and many variations since it seems that its not linking with the C libraries.
Any help? Stuck on this for a while and couldn't find a solution on similar questions
Linux doesn't prepend _ to names when mapping from C to asm symbol names in ELF object files1.
So call printf, not _printf, because there is no _printf in libc.
Whatever "compatibility" code did that is doing it wrong. Only Windows and OS X use _printf, Linux uses printf.
So either you've misconfigured something or defined the wrong setting, or it requires updating / porting to Linux.
Footnote 1: In ancient history (like over 20 years ago), Linux with the a.out file format did use leading underscores on symbol names.
Update: the library uses the NASM preprocessor to %define _scanf scanf and so on, but it requires you to manually define ELF_TYPE by assembling with nasm -d ELF_TYPE.
They could have detected ELF32 or ELF64 output formats on their own, because NASM pre-defines __OUTPUT_FORMAT__. Someone should submit a pull-request to make this detection automatic with code something like this:
%ifidn __OUTPUT_FORMAT__, elf32
%define ELF_TYPE 32
%elifidn __OUTPUT_FORMAT__, elf64
%define ELF_TYPE 64
%endif
%ifdef ELF_TYPE
...
%endif
I'm trying to learn about assembly with the book "Programming from the ground up". The book covers only 32 bit instructions. Is there a way to run the example codes on 64 bit Ubuntu system? I can't understand the stuff on the man page of the GNU assembler but I heard the -m32 flag should do it. But it's not a recognized option.
How do I get the examples on the book to work with ease?
When your assembler and linker are x86_64 versions, the options to produce i386 (32-bit) output are
as --32
ld -m elf_i386
You don't have to use as and ld just because you're working with assembly code. gcc can be used, and in that case you would use -m32.
gcc -m32 -nostdlib myprog.s -o myprog
From the as man page:
Target i386 options:
[--32|--n32|--64] [-n]
[-march=CPU[+EXTENSION...]] [-mtune=CPU]
I'm not sure if it works, just try --32 or --n32.
(-m32 seems to ge the corresponding gcc flag.)
Creating a 32-bit executable on a 64-bit PC requires that you "warn" the linker that a 32-bit elf file is coming:
$ nasm -f elf -g -F stabs eat.asm
$ ld -o eat eat.o -melf_i386
That's what the melf_i386 directive does: It tells ld that the eat.o file is an elf32 linkable object file. The invocation of NASM is the same as you'd use on a 32-bit PC.
Thanks #Jeff Duntemann
I'am reading this Tuto, and I'am trying to link the application using this command: ld test.o –o test.bin, the linker doesn't recognize the -o option :
ld: cannot find –o: No such file or directory
Using ld -help the option -o exist but i don't understand why I'am getting this problem.
This is the linker version.
$ ld -version
GNU ld (GNU Binutils for Ubuntu) 2.24
Copyright 2013 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
My good eyes and my bitter experience tell me that you must have copied/pasted some text coming from MS-Office where the dash (-) has been converted to another dash which is unicode or whatever. Notice the length of the dash character in your text.
Actually, the tuto you were refering to is the one at fault, ex in this line:
ld –Ttext 0x7c00 --oformat=binary test.o –o test.bin
Note the 2 infamous "long-dashes" that cannot work on a command line.
Your command as-is, followed by the retyped command. notice something?
ld test.o –o test.bin # long dash, fails
ld test.o -o test.bin # good one, short dash
Since the dash is not the correct one, ld assumes that this is an object file and tries to open it, hence the error.
This question already has answers here:
Assembling 32-bit binaries on a 64-bit system (GNU toolchain)
(2 answers)
Closed 6 years ago.
I have program written in 32 bit assembly language... Now I just can't compile it on 64 bit OS. On our school they are specific and program has to be written in 32 bit version. Here is my program:
bits 32
extern _printf
global _start
section .data
message db "Hello world!!", 10, 0
section .text
_start:
pushad
push dword message
call _printf
add esp, 4
popad
ret
Any idea? I have tried so many ways to compile that.
Error output after compiling:
nasm -f elf64 vaja4.asm
ld vaja4.o -o vaja4
./vaja4
output:
vaja4.o: In function `_start':
vaja4.asm:(.text+0x7): undefined reference to `_printf'
First change _printf to printf and the _start symbol to main, then use gcc to link the object file, which will automatically link it to libc, you need to do that because AFAIK you can't link to libc without a main. Also you should use elf32 not elf64 when assembling because the code has 32 bits instructions :
bits 32
extern printf
global main
section .data
message db "Hello world!!", 10, 0
section .text
main:
pushad
push dword message
call printf
add esp, 4
popad
ret
And build with:
nasm -f elf32 vaja4.asm
gcc -m32 vaja4.o -o vaja4
$./test
$Hello world!!
Edit:
Since you're now compiling 32-bit code on a 64-bit system, you will need to install the 32-bit version of the libraries
apt-get install ia32-libs
On Ubuntu 12.10, you need to install development packages first
sudo apt-get update
sudo apt-get install libc6-dev-i386
for
gcc -m32 vaja4.o -o vaja4
to work.
I doubt that the error you see is because of 32/64 bit issue. The error that you see i.e
vaja4.asm:(.text+0x7): undefined reference to `_printf'
is clearly telling you the symbol _printf is undefined which means that the library for printf function is not being linked.
your linking step i.e
ld vaja4.o -o vaja4
does not include any libraries. You need to link your program with a library that can provide definition of the printf function. I believe ld should pick the library it self without bothering you with these messages but because it is not able to find a suitable C library for this function, I guess you dont have the required libraries i.e either 32 bit or 64 library is missing.
Anyway, plz try the following sequence of commands to assemble and link your program:
nasm -f elf vaja4.asm
ld -m elf_i386 vaja4.o vaja4
./vaja4
It looks to me like you forgot to link against the C library, which is the part that provides the printf function (and others):
ld vaja4.o -o vaja4 -lc
I'm having difficulty with the linker when it comes to compiling a sample program that uses the POSIX aio library (e.g. aio_read(), aio_write(), etc) on Linux.
I'm running Ubuntu with a 2.6 kernel, and have used the apt-get utility to install libaio. But even though I'm linking with the aio library, the compiler still gives me linker errors.
root#ubuntu:/home# g++ -L /usr/lib/libaio.a aio.cc -oaio
/tmp/cc5OE58r.o: In function `main':
aio.cc:(.text+0x156): undefined reference to `aio_read'
aio.cc:(.text+0x17b): undefined reference to `aio_error'
aio.cc:(.text+0x191): undefined reference to `aio_return'
collect2: ld returned 1 exit status
Where are all these aio_x functions actually defined, if not in the library libaio.a?
I also had issues linking against libaio in spite of the aio package being correctly installed and the -lrt flag being present.
It turned out that placing -l flags later (for example, last) in the gcc command invocation sometimes fixes this issue. I stumbled upon this solution here on Stack Overflow.
I stopped doing this:
gcc -Wall -Werror -g -o myExe -lrt myExe.c
And started doing this:
gcc -Wall -Werror -g -o myExe myExe.c -lrt
EDIT: according the the man page, libaio.so is not the correct library to link to:
man aio_read
SYNOPSIS
#include <aio.h>
int aio_read(struct aiocb *aiocbp);
Link with -lrt.
so you should link with this:
g++ -lrt aio.cc -o aio
The way libraries work with gcc is like this:
-L adds directory dir to the list of directories to be searched for -l.
-l adds a library itself, if the file is named libsomename.so, you just use "-lsomename"
Does -L specify the search path and -l specifies the actual library?
You want -laio in order to link to libaio. The argument of -o is what you want the compiled executable to be called.
Try:
sudo apt-get install libaio-dev
Then make sure you specify -laio on the link line.
Okay, Evan Teran is correct - it worked when I linked with -lrt. It seems the aio_x functions are defined in a general POSIX extension library.
Thanks, Evan.