This is the mail archive of the mailing list for the binutils 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: How to avoid unnecessary R_IA64_FPTR64LSB in executable?

On Wed, 2005-04-27 at 16:43, H. J. Lu wrote:
> 1. When we export a function in executable, whose function pointer is
> used in executable and which is referenced by a DSO, can we create a
> R_IA64_FPTR64LSB in executable only when there is a dynamic
> R_IA64_FPTR64LSB reference?

I don't know if I can help with this thread.  I don't have enough
experience dealing with linker related issues.

However, it does occur to me to ask what happens with programs that use
dlopen.  You are assuming you can detect all DSO references at link
time, but can't we dlopen a library that wasn't initially linked in?  In
that case, you would have to create the FPTR64LSB reloc for anything
that might be usable from a DSO, regardless of whether we see a
reference at link time.  That seems to be what Richard meant when he
referred to --export-dynamic.

The Software Conventions and Runtime Architecture guide says an direct
dynamically-linked call effectively is handled the same as an indirect
call, which implies that it needs a function descriptor.  But I don't
think this means we need an official function descriptor.

I see that i_prot1 got added to the dynamic symbol table, even though
--export-dynamic wasn't used, simply because it was used in the
library.  This presumably means a dlopen'ed library could also use
i_prot1.  Suppose that dlopen'ed library library takes the address of
i_prot1, and then this address gets compared with the one we took in
main.  We would have needed to create an official function descriptor
for this to work.  This implies that anything that ended up in the
dynamic symbol table needs an official function descriptor if there was
an FPTR reloc in the executable, even if there are no dynamic FPTR
relocs in any shared libraries referenced at the initial link time. 
Again, this seems to agree with what Richard said.
Jim Wilson, GNU Tools Support,

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