I wrote simple x86 assembly routine:
$ cat asm.s
.global foo
.section .text
foo:
nop
ret
And compiled it with
$ gcc -c -g asm.s -o asm.o
But when I do objdump --dwarf asm.o, it does not display any info about function foo. Looks like, gcc does not create .debug_info details about foo.
BTW, there is a entry of foo in .symtab.
Any ideas?
The error is in the objdump command. use the following command, and it will show the assembly listing of your function:
objdump -d -M intel -S asm.o
Now you updated the question - if you want to include debug info then invoke the assembler with:
gcc -gdwarf2 -c asm.s -o asm.o
Now objdump --dwarf will display the debug info.
Related
How do I get assembly code instructions addresses using g++,
I can print the assembly code from g++ using the following command
g++ -S -masm=intel
I get the the assembly code but it doesn't include the instruction address.
The -S switch causes g++ to emit the assembly it sends to the assembler. This is not a dump of an object and thus doesn't have addresses.
To get a dump of the object g++ generates, first compile into an object file:
g++ -c foo.cpp
Then use objdump to dump the object file:
objdump -d -Mintel foo.o
I am currently developing an OS for learning purposes, and it's been working fine until now. Then I tried to call an assembler function, compiled with nasm, -fwin32, from C code, but all I got was an "undefined reference" error. I have created a small example in pure assembler, which has the same problem, but is easily understandable and way smaller:
It includes two files:
test.asm:
[bits 32]
global _testfunc
_testfunc:
ret
test2.asm:
[bits 32]
extern _testfunc
global _testfunc2
_testfunc2:
call _testfunc
ret
Here is my compiler / linker script (using windows batch files):
nasm.exe -f win32 test.asm -o test.o
nasm.exe -f win32 test2.asm -o test2.o
ld test.o test2.o -o output.tmp
This results in the error:
test2.o:test2.asm:(.text+0x1): undefined reference to `testfunc'
To extend the question, the same happens when the function is called from C:
test.c:
extern void testfunc(void);
void start()
{
testfunc();
}
With this linker script:
gcc -ffreestanding -c test.c -o testc.o
nasm.exe -f win32 test.asm -o test.o
ld test.o testc.o -o output.tmp
In test.o, test2.o and testc.o, it always says _testfunc, so the error has nothing to do with leading underscores!
In my MinGW setup you need a section directive before the code.
; foo.asm
[bits 32]
global _testfunc
section .text
_testfunc:
ret
Then assemble to win32 format:
nasm -fwin32 foo.asm -o foo.o
Now you can check that testfunc is there:
$ nm foo.o
00000000 a .absolut
00000000 t .text
00000001 a #feat.00
00000000 T _testfunc
The T means text section global, so we're good to go.
Note I'd avoid naming anything test since this is a shell command. This can cause endless grief.
The C function is as you showed it, but name the file something else:
// main.c
extern void testfunc(void);
int main(void)
{
testfunc();
return 0;
}
Then to build an executable let gcc do the heavy lifting because ld sometimes needs arcane arguments.
gcc -ffreestanding main.c foo.o -o main
Your missing something important, your code is not in a code section!
Your asm files should look like the following:
test.asm
global _testfunc
section .text ; <<<< This is important!!!
; all code goes below this!
_testfunc:
ret
test2.asm
extern _testfunc
global _testfunc2
section .text ; <<<< Again, this is important!!!
_testfunc2:
call _testfunc
ret
I'm trying to learn assembly and I'm using Nasm v2.10.07 on Mac OS X (Snow Leopard).
I can compile, but I need to read the Debug file, that is a .o file.
This is what I compile:
global _main
section.data
M db 5,4,3,2,1
dim equ $-M
section.text
_main:
mov edi, M
mov eax, 0
mov ebx, 1
int 80h
This is how I compile:
nasm -f elf -g -F stabs myfile.asm -o myfile.o
And this is the result:
ELF����������������������#�������4�����(�
�������������������������������������������������������������������–������������������������������������?��������������������������������0��M��������������������������������Ä��ê���������������"����������������2������������������*��� �����������P�����������������4��������������`��T����������������:��������������¿��������������������C��� �����������–��0���������������ø����∏����ª���ÕÄ�%define $�The Netwide Assembler 0.98.40 (Apple Computer, Inc. build 11)���.text�.comment�.shstrtab�.symtab�.strtab�.rel.text�.stab�.stabstr�.rel.stab��%d����������������������������Òˇ�������������Òˇ������������������������������������������������������Òˇ�������������,�������������myfile.asm�section.data�M�dim�section.text�_main��%define $_%1 ������%define������������d�����������D����������D���������D��
�������D� ��������D�
�����%define $_%�myfile.asm��%de����� �����,�����8�����D�����P�����
So, what should I do to read in the correct way the debug without those strange symbols?
To show the contents of the .stabs section, use objdump -g myfile.o or objdump -G myfile.o
To get the full source code with line numbers taken from the debug section, use objdump -S -l myfile.o
I am trying to compile and link a simple "hello, world!" program with GCC. This program uses the "printf" C function. The problem that I am having is that the terminal throws back multiple errors. I am running Archlinux, compiling with NASM, linking with GCC. Here is my code:
; ----------------------------------------------------------------------------
; helloworld.asm
;
; Compile: nasm -f elf32 helloworld.asm
; Link: gcc helloworld.o
; ----------------------------------------------------------------------------
SECTION .data
message db "Hello, World",0
SECTION .text
global main
extern printf
section .text
_main:
push message
call printf
add esp, 4
ret
The errors that I receive are as follows:
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
collect2: error: ld returned 1 exit status
Can someone tell me what is causing these errors and what I need to do to fix them?
Thanks in advance,
RileyH
For such things, you should first understand what exactly gcc is doing. So use
gcc -v helloworld.o -o helloworld
and what is happenning is that you have a 64 bits Linux and linking a 32 bits object in it. So try with
gcc -m32 -v helloworld.o -o helloworld
But I think that you should avoid coding assembly today (optimizing compilers do a better work than you can reasonably do). If you absolutely need a few assembly instructions, put some asm in your C code.
BTW, you could compile with gcc -fverbose-asm -O -wall -S helloworld.c and look inside the generated helloworld.s; and you could also pass .s files to gcc
How can I tell, with something like objdump, if an object file has been built with -fPIC?
The answer depends on the platform. On most platforms, if output from
readelf --relocs foo.o | egrep '(GOT|PLT|JU?MP_SLOT)'
is empty, then either foo.o was not compiled with -fPIC, or foo.o doesn't contain any code where -fPIC matters.
I just had to do this on a PowerPC target to find which shared object (.so) was being built without -fPIC. What I did was run readelf -d libMyLib1.so and look for TEXTREL. If you see TEXTREL, one or more source files that make up your .so were not built with -fPIC. You can substitute readelf with elfdump if necessary.
E.g.,
[user#host lib]$ readelf -d libMyLib1.so | grep TEXT # Bad, not -fPIC
0x00000016 (TEXTREL)
[user#host lib]$ readelf -d libMyLib2.so | grep TEXT # Good, -fPIC
[user#host lib]$
And to help people searching for solutions, the error I was getting when I ran my executable was this:
root#target:/# ./program: error while loading shared libraries: /usr/lib/libMyLi
b1.so: R_PPC_REL24 relocation at 0x0fc5987c for symbol 'memcpy' out of range
I don't know whether this info applies to all architectures.
Source: blogs.oracle.com/rie
I assume, what you really want to know is whether or not a shared library is composed from object files compiled with -fPIC.
As already mentioned, if there are TEXTRELs, then -fPIC was not used.
There is a great tool called scanelf which can show you the symbols that caused .text relocations.
More information can be found at HOWTO Locate and Fix .text Relocations TEXTRELs.
-fPIC means that code will be able to execute in addresses different form the address that was compile for.
To do it , disasambler will look like this....
call get_offset_from_compilation_address
get_offset_from_compilation_address: pop ax
sub ax, ax , &get_offset_from_compilation_address
now in ax we have an offset that we need to add to any access to memory.
load bx, [ax + var_address}
readelf -a *.so | grep Flags
Flags: 0x50001007, noreorder, pic, cpic, o32, mips32
This should work most of the time.
Another option to distinguish whether your program is generated wit -fPIC option:
provided that your code has -g3 -gdwarf-2 option enabled when compiling.
other gcc debug format may also contains the macro info:
Note the following $'..' syntax is assumes bash
echo $' main() { printf("%d\\n", \n#ifdef __PIC__\n__PIC__\n#else\n0\n#endif\n); }' | gcc -fPIC -g3
-gdwarf-2 -o test -x c -
readelf --debug-dump=macro ./test | grep __PIC__
such a method works because gcc manual declares that if -fpic is used, PIC is defined to 1, and
if -fPIC used, PIC is 2.
The above answers by checking the GOT is the better way. Because the prerequest of -g3 -gdwarf-2 I guess seldom being used.
From The Linux Programming Interface:
On Linux/x86-32, it is possible to create a shared library using
modules compiled without the –fPIC option. However, doing so loses
some of the benefits of shared libraries, since pages of program text
containing position-dependent memory references are not shared across
processes. On some architectures, it is impossible to build shared
libraries without the –fPIC option.
In order to determine whether an existing object file has been
compiled with the –fPIC option, we can check for the presence of the
name _GLOBAL_OFFSET_TABLE_ in the object file’s symbol table, using
either of the following commands:
$ nm mod1.o | grep _GLOBAL_OFFSET_TABLE_
$ readelf -s mod1.o | grep _GLOBAL_OFFSET_TABLE_
Conversely, if either of the following equivalent commands yields any
output, then the specified shared library includes at least one object
module that was not compiled with –fPIC:
$ objdump --all-headers libfoo.so | grep TEXTREL
$ readelf -d libfoo.so | grep TEXTREL
However, neither above quoting nor any answer of this question works for x86_64.
What I've observed on my x86_64 Ubuntu machine is that, whether specifying -fPIC or not, it would generate fPIC .o. That is
gcc -g -Wall -c -o my_so.o my_so.c // has _GLOBAL_OFFSET_TABLE_
gcc -g -Wall -fPIC -c -o my_so_fpic.o my_so.c // has _GLOBAL_OFFSET_TABLE_
readelf -s my_so.o > 1.txt && readelf -s my_so_fpic > 2.txt && diff 1.txt 2.txt
has no difference and both my_so.o and my_so_fpic.o can be used to create a shared library.
In order to generate non fpic object file, I found a gcc flag called -fno-pic in the first comment of How to test whether a Linux binary was compiled as position independent code? .
This works,
gcc -g —Wall -fno-pic -c -o my_so_fnopic.o my_so.c // no _GLOBAL_OFFSET_TABLE_
and
gcc -g -Wall -shared -o libdemo.so my_so_fnopic.o
gives error:
/usr/bin/ld: my_so_fnopic.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
collect2: error: ld returned 1 exit status
can not create a shared library with non pic .o.