* 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: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-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-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).