CODEWITHSUNDEEP
clinuxassemblylinkerelf
lllllllllllll
lllllllllllll

Reputation: 9090

How can a linker determine the address of certain data in the .rodata section?

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?

Upvotes: 2

Views: 811

Answers (1)

Jester
Jester

Reputation: 58762

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.

Upvotes: 1

Related Questions