* Re: PATCH: Optimize protected call for i386
[not found] ` <20030514074940.A2376@lucon.org>
@ 2003-05-14 23:03 ` Alan Modra
2003-05-14 23:27 ` Richard Henderson
0 siblings, 1 reply; 7+ messages in thread
From: Alan Modra @ 2003-05-14 23:03 UTC (permalink / raw)
To: H. J. Lu; +Cc: gcc
On Wed, May 14, 2003 at 07:49:40AM -0700, H. J. Lu wrote:
> On Wed, May 14, 2003 at 06:24:53PM +0930, Alan Modra wrote:
> > On Tue, May 13, 2003 at 02:27:16PM -0700, H. J. Lu wrote:
> > > How about this patch? It added a new relocation type R_386_PC32_DATA
> > > to distinguish PC relative data reference from PC relative branch.
> >
> > I think it's going to a lot of work just to support non-PIC shared
> > libs. I don't think it's worth bothering really.
>
> The current gcc won't use PIC for calls to protected functions. It
> expects linker will resolve it directly.
I see. I think this is wrong. gcc needs to emit the normal PIC call,
ie. "call foo@PLT" so the the linker can set up a plt entry if
needed. A plt entry is needed for protected symbols so that function
pointer comparisons work, since the x86 ABI uses the .plt entry for
the value of a function symbol referenced by a dynamic object.
Consider liba.so exporting a protected symbol foo. Will a function
pointer, value foo, passed to libb.so compare equal to &foo in
libb.so? What about a function pointer, value foo, passed from
libb.so back to liba.so?
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: PATCH: Optimize protected call for i386
2003-05-14 23:03 ` PATCH: Optimize protected call for i386 Alan Modra
@ 2003-05-14 23:27 ` Richard Henderson
2003-05-14 23:50 ` H. J. Lu
2003-05-14 23:51 ` Alan Modra
0 siblings, 2 replies; 7+ messages in thread
From: Richard Henderson @ 2003-05-14 23:27 UTC (permalink / raw)
To: H. J. Lu, gcc
On Thu, May 15, 2003 at 08:32:53AM +0930, Alan Modra wrote:
> I see. I think this is wrong. gcc needs to emit the normal PIC call,
> ie. "call foo@PLT" so the the linker can set up a plt entry if
> needed.
I disagree.
> A plt entry is needed for protected symbols so that function
> pointer comparisons work, since the x86 ABI uses the .plt entry for
> the value of a function symbol referenced by a dynamic object.
> Consider liba.so exporting a protected symbol foo. Will a function
> pointer, value foo, passed to libb.so compare equal to &foo in
> libb.so? What about a function pointer, value foo, passed from
> libb.so back to liba.so?
None of which has anything to do with call instructions.
If liba.so contains a call to foo, ld *knows* that foo *must*
resolve to the version in liba.so and nowhere else. Thus we
can direct the call to foo without going through a PLT entry.
If you take the address of foo, in *any* DSO, you will not be
using either R_386_PC32 or R_386_PLT32. You'll be using either
R_386_32 or R_386_GOT32.
r~
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: PATCH: Optimize protected call for i386
2003-05-14 23:27 ` Richard Henderson
@ 2003-05-14 23:50 ` H. J. Lu
2003-05-15 0:44 ` Richard Henderson
2003-05-14 23:51 ` Alan Modra
1 sibling, 1 reply; 7+ messages in thread
From: H. J. Lu @ 2003-05-14 23:50 UTC (permalink / raw)
To: Richard Henderson, gcc
On Wed, May 14, 2003 at 04:24:39PM -0700, Richard Henderson wrote:
> On Thu, May 15, 2003 at 08:32:53AM +0930, Alan Modra wrote:
> > I see. I think this is wrong. gcc needs to emit the normal PIC call,
> > ie. "call foo@PLT" so the the linker can set up a plt entry if
> > needed.
>
> I disagree.
Since "call foo" and ".long foo - ." will both generate a R_386_PC32
relocation against foo, linker can't resolve R_386_PC32 against
a protected symbol without knowing how it is used. "call foo@PLT"
solves this problem for linker.
>
> > A plt entry is needed for protected symbols so that function
> > pointer comparisons work, since the x86 ABI uses the .plt entry for
> > the value of a function symbol referenced by a dynamic object.
> > Consider liba.so exporting a protected symbol foo. Will a function
> > pointer, value foo, passed to libb.so compare equal to &foo in
> > libb.so? What about a function pointer, value foo, passed from
> > libb.so back to liba.so?
>
> None of which has anything to do with call instructions.
>
> If liba.so contains a call to foo, ld *knows* that foo *must*
> resolve to the version in liba.so and nowhere else. Thus we
> can direct the call to foo without going through a PLT entry.
>
> If you take the address of foo, in *any* DSO, you will not be
> using either R_386_PC32 or R_386_PLT32. You'll be using either
> R_386_32 or R_386_GOT32.
But the currrent gcc uses R_386_GOTOFF for address of a protected
data or function symbol on x86 when PIC is used. I will say it is
a bug. R_386_GOT32 should be used here. I can provide a testcase
if asked.
H.J.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: PATCH: Optimize protected call for i386
2003-05-14 23:27 ` Richard Henderson
2003-05-14 23:50 ` H. J. Lu
@ 2003-05-14 23:51 ` Alan Modra
2003-05-15 0:42 ` Richard Henderson
1 sibling, 1 reply; 7+ messages in thread
From: Alan Modra @ 2003-05-14 23:51 UTC (permalink / raw)
To: Richard Henderson, H. J. Lu, gcc
On Wed, May 14, 2003 at 04:24:39PM -0700, Richard Henderson wrote:
> On Thu, May 15, 2003 at 08:32:53AM +0930, Alan Modra wrote:
> > I see. I think this is wrong. gcc needs to emit the normal PIC call,
> > ie. "call foo@PLT" so the the linker can set up a plt entry if
> > needed.
>
> I disagree.
>
> > A plt entry is needed for protected symbols so that function
> > pointer comparisons work, since the x86 ABI uses the .plt entry for
> > the value of a function symbol referenced by a dynamic object.
> > Consider liba.so exporting a protected symbol foo. Will a function
> > pointer, value foo, passed to libb.so compare equal to &foo in
> > libb.so? What about a function pointer, value foo, passed from
> > libb.so back to liba.so?
>
> None of which has anything to do with call instructions.
Well, it may be that the linker will set up a plt entry anyway,
thus making the function pointer comparisons work properly. The
problem is that if gcc emits "call foo" for protected syms, you'll get
an R_386_PC32 reloc on foo. How is the linker supposed to distinguish
this reloc from an R_386_PC32 on ".long foo - ."? In the second case,
you really want to use the plt entry address.
> If liba.so contains a call to foo, ld *knows* that foo *must*
> resolve to the version in liba.so and nowhere else. Thus we
> can direct the call to foo without going through a PLT entry.
Exactly. ld can do this even when gcc emits "call foo@PLT".
> If you take the address of foo, in *any* DSO, you will not be
> using either R_386_PC32 or R_386_PLT32. You'll be using either
> R_386_32 or R_386_GOT32.
Does the ABI preclude use of R_386_PC32 from assembly?
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: PATCH: Optimize protected call for i386
2003-05-14 23:51 ` Alan Modra
@ 2003-05-15 0:42 ` Richard Henderson
2003-05-15 0:51 ` Alan Modra
0 siblings, 1 reply; 7+ messages in thread
From: Richard Henderson @ 2003-05-15 0:42 UTC (permalink / raw)
To: H. J. Lu, gcc
On Thu, May 15, 2003 at 09:21:07AM +0930, Alan Modra wrote:
> How is the linker supposed to distinguish
> this reloc from an R_386_PC32 on ".long foo - ."?
Who cares? You can't generate this from C. As for assembly,
"don't do that if you care about pointer equality".
Indeed, I can think of reasons to use this pcrel form if you
_don't_ want pointer equality. Such as in .eh_frame data.
r~
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: PATCH: Optimize protected call for i386
2003-05-14 23:50 ` H. J. Lu
@ 2003-05-15 0:44 ` Richard Henderson
0 siblings, 0 replies; 7+ messages in thread
From: Richard Henderson @ 2003-05-15 0:44 UTC (permalink / raw)
To: H. J. Lu; +Cc: gcc
On Wed, May 14, 2003 at 04:50:07PM -0700, H. J. Lu wrote:
> > If you take the address of foo, in *any* DSO, you will not be
> > using either R_386_PC32 or R_386_PLT32. You'll be using either
> > R_386_32 or R_386_GOT32.
>
> But the currrent gcc uses R_386_GOTOFF for address of a protected
> data or function symbol on x86 when PIC is used. I will say it is
> a bug.
Agreed.
> R_386_GOT32 should be used here. I can provide a testcase if asked.
File a PR so it does not get lost.
r~
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: PATCH: Optimize protected call for i386
2003-05-15 0:42 ` Richard Henderson
@ 2003-05-15 0:51 ` Alan Modra
0 siblings, 0 replies; 7+ messages in thread
From: Alan Modra @ 2003-05-15 0:51 UTC (permalink / raw)
To: Richard Henderson, H. J. Lu, gcc
On Wed, May 14, 2003 at 05:40:03PM -0700, Richard Henderson wrote:
> On Thu, May 15, 2003 at 09:21:07AM +0930, Alan Modra wrote:
> > How is the linker supposed to distinguish
> > this reloc from an R_386_PC32 on ".long foo - ."?
>
> Who cares? You can't generate this from C. As for assembly,
> "don't do that if you care about pointer equality".
>
> Indeed, I can think of reasons to use this pcrel form if you
> _don't_ want pointer equality. Such as in .eh_frame data.
Yeah, OK, fair enough. HJ, go ahead and commit your
SYMBOL_CALLS_LOCAL patch (and post it to the binutils list).
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2003-05-15 0:51 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20030513013909.GQ2166@bubble.sa.bigpond.net.au>
[not found] ` <20030512184927.A14308@lucon.org>
[not found] ` <20030513015330.GR2166@bubble.sa.bigpond.net.au>
[not found] ` <20030512185613.A14533@lucon.org>
[not found] ` <20030513020400.GS2166@bubble.sa.bigpond.net.au>
[not found] ` <20030512192302.A14731@lucon.org>
[not found] ` <20030513135912.GA966@bubble.sa.bigpond.net.au>
[not found] ` <20030513142716.A20059@lucon.org>
[not found] ` <20030514085453.GA957@bubble.sa.bigpond.net.au>
[not found] ` <20030514074940.A2376@lucon.org>
2003-05-14 23:03 ` PATCH: Optimize protected call for i386 Alan Modra
2003-05-14 23:27 ` Richard Henderson
2003-05-14 23:50 ` H. J. Lu
2003-05-15 0:44 ` Richard Henderson
2003-05-14 23:51 ` Alan Modra
2003-05-15 0:42 ` Richard Henderson
2003-05-15 0:51 ` Alan Modra
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).