Question

So the test platform is on Linux 32 bit.

I use gcc to generate a obj file of quickSort in this way:

gcc -S quickSort.c

and the generated quickSort.o is a relocatable ELF:

#file quickSort.o quickSort.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped

I then use objdump to disassemble it :

objdump -d quickSort.o

and looking into the asm file generated, I am confused with this:

51:   b8 00 00 00 00          mov    $0x0,%eax
56:   89 04 24                mov    %eax,(%esp)
59:   e8 fc ff ff ff          call   5a <main+0x5a>
5e:   c7 44 24 3c 00 00 00    movl   $0x0,0x3c(%esp) 

The above code is call printf function and print out a string, and if I compile quicksort.c into quicksort.s, it should like this:

   movl    $.LC0, %eax
   movl    %eax, (%esp)
   call    printf

So by looking at the relocation table, I can easily find out the relation between "5a" and printf, and I am sure linker can use this way to relocate printf and substitute "fc ff ff ff" into the real address of printf,

But I am confused with how the address of .LC0 (which is a string in the .rodata section) be relocated? I cannot find any clue in the relation table (I got the relocation table using readelf -r quickSort.o)

Could anyone give me some help about how the linker will find the real memory address of some data in the .rodata section?

Was it helpful?

Solution

It's done in the same way. You should be seeing a relocation entry against .rodata, where .rodata means the start address of the part of .rodata that's in the current object file.

Note that objdump -dr might be a better tool for the job.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top