From: Christophe LYON <christophe.lyon@st.com>
To: Christophe LYON <christophe.lyon@st.com>,
binutils@sourceware.org, Nick Clifton <nickc@redhat.com>,
Phil Blundell <pb@reciva.com>
Subject: Re: linker crash in arm stub generation
Date: Wed, 17 Jun 2009 15:44:00 -0000 [thread overview]
Message-ID: <4A390CF5.3000505@st.com> (raw)
In-Reply-To: <20090615175935.GA22200@caradoc.them.org>
Hi Daniel,
Thank you for your answer, but I am afraid things are still not clear to
me, despite reading your answer several times :-(
(part of the confusion probably comes from the fact that I deal with
different architectures, too...)
>> I have started to look at this problem more closely, and I have one
>> question: in elf32-arm.c:allocate_dynrelocs(), there is this comment:
>>
>> /* If this symbol is not defined in a regular file, and we are
>> not generating a shared library, then set the symbol to this
>> location in the .plt. This is required to make function
>> pointers compare as equal between the normal executable and
>> the shared library. */
>>
>> Why is the behaviour different when generating a shared lib?
>>
>> I thought I had understood the comment about function pointers
>> comparison, but I am wondering now....
>
> A PLT entry with a non-zero address is used as the canonical location
> of the function.
This "canonical" location is only used by the dynamic linker, when it
patches the dyn relocs pointing to this symbol, right? (when the address
of the function is stored in a constant pool for instance, or in GOT)
> This is only ever required in an executable, never
> in a shared library. If all accesses to the address are PIC - which
> they must be, in a shared library - then they can be easily adjusted
> to point to the function's address.
Easy because the dyn linker needs to patch the GOT only (ie one entry
instead of several references)?
> And it's better to do that,
> because calls through those pointers will go directly to the function
> instead of to the PLT.
So you mean that in a shared lib, PLT are generated, but not executed
because the dyn linker manages to make these indirect calls go directly
to the function?
But then, how is symbol preemption handled? I mean, if a shared lib is
actually shared, ie used by two different executables, and one of them
preempts the function definition, but not the other, I think the calls
need to go through the PLT so that different GOTs are used to reach
different functions.
> In an executable, this might not be the case. For instance you might
> have the address of the funtion in a constant pool in the text
> segment. If that happens, the linker must fix the address of the
> function at static link time, even if the definition turns out to be
> in a shared library.
Why couldn't this be performed at load time?
> Such code is (or is supposed to be, anyway) rejected in shared
> objects.
>
I thought your answer would help me solve my actual problem, but since
it seems that I need better understanding, I will expose my actual
question here:
If I am generating a shared lib, let's say that some ARM code references
a THUMB function in a shared lib.
As the target is in a shared lib, we need to have a PLT generated.
But, we also need to know if we need to change modes, and if we need a
long branch stub.
However, because of the comment I mentioned earlier, the destination is
not recorded as being the PLT, so we don't know the actual distance, and
the symbol type is not switched to ARM type.
This scenario is handled properly when generating an executable, but
when generating a shared lib, the current generation is broken.
Christophe.
PS: I have noted that Phil Blundell has inadvertently committed a wrong
patch for the issue being discussed (as part of another commit of his).
I don't know if it should be cancelled separately or if it can't wait
until I propose a full patch + testcase.
next prev parent reply other threads:[~2009-06-17 15:34 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-11 17:09 Phil Blundell
2009-06-12 12:36 ` Nick Clifton
2009-06-12 13:19 ` Christophe LYON
2009-06-12 13:49 ` Nick Clifton
2009-06-12 14:06 ` Daniel Jacobowitz
2009-06-12 14:13 ` Christophe LYON
2009-06-15 14:22 ` Christophe LYON
2009-06-15 17:59 ` Daniel Jacobowitz
2009-06-17 15:44 ` Christophe LYON [this message]
2009-06-17 16:09 ` Phil Blundell
2009-06-17 18:10 ` Daniel Jacobowitz
2009-06-18 14:25 ` Christophe LYON
2009-06-18 14:36 ` Christophe LYON
2009-06-22 9:24 ` Nick Clifton
2009-06-22 11:33 ` Christophe LYON
2009-08-26 1:21 ` Fix Thumb-2 shared libraries Daniel Jacobowitz
2009-08-26 3:11 ` Daniel Jacobowitz
2009-09-09 18:36 ` Daniel Jacobowitz
2009-09-14 12:30 ` Daniel Jacobowitz
2009-08-26 10:39 ` Christophe LYON
2009-08-26 15:00 ` Daniel Jacobowitz
2009-08-26 17:24 ` Christophe LYON
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A390CF5.3000505@st.com \
--to=christophe.lyon@st.com \
--cc=binutils@sourceware.org \
--cc=nickc@redhat.com \
--cc=pb@reciva.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).