This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: address of function


On Tue, 2005-01-11 at 15:30 +0100, Jakub Jelinek wrote:
> without -fpic, there will be something like:
>      1: 080482a0     8 FUNC    GLOBAL DEFAULT  UND getpid@GLIBC_2.0 (2)
> in .dynsym while with -fpic:
>      2: 00000000     8 FUNC    GLOBAL DEFAULT  UND getpid@GLIBC_2.0 (2)
> 0x080482a0 is address of the .plt slot.
> 
> The reason for this is that in non-pic code, the address of the function
> (getpid in this case) needs to be resolved at link time, and the non-zero

This means that the loader is not allowed to change the address of that
PLT slot ever ?

> st_value tells the dynamic linker to resolve all non-PLT dynamic lookups
> to the PLT slot in the binary (C requires the pointer equality).

I could not find in the "elf" spec and its various ABI supplements
something which said specifically that the non-PLT dynamic lookups must
resolve to the PLT slot in the main binary (although that is what I
noticed with gdb). Actually, I found out about this while verifying C
pointer equality between shared libraries and the main binary file.

> If there is only pic code taking that address, the address is stored into
> a .got slot and therefore can be changed at dynamic link time to the
> actual getpid's address, so also all shared libraries can resolve
> the function to its real address.

In that case, I can use any of the relocation entries for that symbol to
find the address of one of its GOT slots and then read the GOT to get
the address of the code, I guess. Am I right ?

Mathieu
-- 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]