public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* Re: [PATCH] Make calls in virtual thunks local if possible
@ 2003-06-25 16:51 John David Anglin
  2003-06-25 21:47 ` Jason Merrill
  2003-06-26  7:50 ` Jakub Jelinek
  0 siblings, 2 replies; 3+ messages in thread
From: John David Anglin @ 2003-06-25 16:51 UTC (permalink / raw)
  To: gcc-patches; +Cc: jakub, binutils

This patch has broken the hppa-unknown-linux-gnu port.

/home/dave/gcc-3.4/objdir/gcc/xgcc -shared-libgcc -B/home/dave/gcc-3.4/objdir/gcc/ -nostdinc++  -L/home/dave/gcc-3.4/objdir/hppa-linux/libstdc++-v3/src -L/home/dave/gcc-3.4/objdir/hppa-linux/libstdc++-v3/src/.libs -B/home/dave/opt/gnu/hppa-linux/bin/ -B/home/dave/opt/gnu/hppa-linux/lib/ -isystem /home/dave/opt/gnu/hppa-linux/include -isystem /home/dave/opt/gnu/hppa-linux/sys-include -shared -nostdlib /home/dave/opt/gnu/lib/crti.o /home/dave/gcc-3.4/objdir/gcc/crtbeginS.o  .libs/allocator-inst.o .libs/codecvt.o .libs/complex_io.o .libs/concept-inst.o .libs/ctype.o .libs/demangle.o .libs/ext-inst.o .libs/fstream-inst.o .libs/functexcept.o .libs/globals.o .libs/io-inst.o .libs/ios.o .libs/istream-inst.o .libs/limits.o .libs/locale.o .libs/locale-inst.o .libs/localename.o .libs/misc-inst.o .libs/ostream-inst.o .libs/sstream-inst.o .libs/stdexcept.o .libs/streambuf-inst.o .libs/string-inst.o .libs/strstream.o .libs/valarray-inst.o .libs/wstring-inst.o .libs/codecvt_members.o .lib!
 s/collate_members.o .libs/ctype_members.o .libs/messages_members.o .libs/monetary_members.o .libs/numeric_members.o .libs/time_members.o .libs/basic_file.o .libs/c++locale.o -Wl,--whole-archive ../libmath/.libs/libmath.a ../libsupc++/.libs/libsupc++convenience.a -Wl,--no-whole-archive  -L/home/dave/gcc-3.4/objdir/hppa-linux/libstdc++-v3/src -L/home/dave/gcc-3.4/objdir/hppa-linux/libstdc++-v3/src/.libs -lm ../libmath/.libs/libmath.a -lm ../libsupc++/.libs/libsupc++convenience.a -lm -L/home/dave/gcc-3.4/objdir/gcc -L/home/dave/opt/gnu/hppa-linux/bin -L/home/dave/opt/gnu/hppa-linux/lib -L/home/dave/opt/gnu/lib -L/home/dave/opt/gnu/lib/gcc-lib/hppa-linux/3.4 -L/home/dave/opt/gnu/lib/gcc-lib/hppa-linux/3.4/../../../../hppa-linux/lib -L/home/dave/opt/gnu/lib/gcc-lib/hppa-linux/3.4/../../.. -lgcc_s -lgcc -lc -lgcc_s -lm -lgcc_s -lgcc -lc -lgcc_s   /home/dave/gcc-3.4/objdir/gcc/crtendS.o /home/dave/opt/gnu/lib/crtn.o  -Wl,-O1 -Wl,--version-script=libstdc++-symbol.ver -Wl,-soname -W!
 l,libstdc++.so.6 -o .libs/libstdc++.so.6.0.0
/home/dave/opt/gnu/bin/ld: BFD 2.14.90 20030602 internal error, aborting at ../../src/bfd/elf32-hppa.c line 3864 in elf32_hppa_relocate_section

/home/dave/opt/gnu/bin/ld: Please report this bug.

collect2: ld returned 1 exit status

I'm not entirely sure what's wrong but it appears that ld can't handle
the following situation (from io-inst.s):

        .section        .gnu.linkonce.t._ZNSdD1Ev,"ax",@progbits
	.align 4
	.weak   _ZNSdD1Ev
	.type   _ZNSdD1Ev, @function
.LFB1804:
_ZNSdD1Ev:

	...

        .set    .LTHUNK1,_ZNSdD1Ev

	...

        .data
	.align 4
.LTHN0:
	.word P'.LTHUNK1

The P' is a procedure descriptor (plabel) constructor.  Using a procedure
descriptor for the branch from the thunk was necessary under hpux.  This
prevents the linker from adding a stub between the branch and its target.

This technique was carried over to linux.  It might be possible to
change linux to use a simple pc-relative branch in the thunk.  The
stubs inserted by the linux linker don't mess with the return pointer
(except in the multispace model which the kernel doesn't currently
support).  Possibly, we won't get a stub at all if the branch is local.

However, it can be seen that the thunk follows the function.  As a result,
we can't be certain that a pc-relative branch will be able to reach the
start of the function.  It would be better to have the thunk just before the
function if possible.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] Make calls in virtual thunks local if possible
  2003-06-25 16:51 [PATCH] Make calls in virtual thunks local if possible John David Anglin
@ 2003-06-25 21:47 ` Jason Merrill
  2003-06-26  7:50 ` Jakub Jelinek
  1 sibling, 0 replies; 3+ messages in thread
From: Jason Merrill @ 2003-06-25 21:47 UTC (permalink / raw)
  To: John David Anglin; +Cc: gcc-patches, jakub, binutils

On Wed, 25 Jun 2003 11:46:20 -0400 (EDT), "John David Anglin" <dave@hiauly1.hia.nrc.ca> wrote:

> However, it can be seen that the thunk follows the function.  As a result,
> we can't be certain that a pc-relative branch will be able to reach the
> start of the function.  It would be better to have the thunk just before the
> function if possible.

Indeed.  Jakub, can you make that change?

Jason

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] Make calls in virtual thunks local if possible
  2003-06-25 16:51 [PATCH] Make calls in virtual thunks local if possible John David Anglin
  2003-06-25 21:47 ` Jason Merrill
@ 2003-06-26  7:50 ` Jakub Jelinek
  1 sibling, 0 replies; 3+ messages in thread
From: Jakub Jelinek @ 2003-06-26  7:50 UTC (permalink / raw)
  To: John David Anglin; +Cc: gcc-patches, binutils

On Wed, Jun 25, 2003 at 11:46:20AM -0400, John David Anglin wrote:
> This technique was carried over to linux.  It might be possible to
> change linux to use a simple pc-relative branch in the thunk.  The
> stubs inserted by the linux linker don't mess with the return pointer
> (except in the multispace model which the kernel doesn't currently
> support).  Possibly, we won't get a stub at all if the branch is local.

The output_mi_thunk target hook should for binds_local_p function create
a tail call to function. For
void foo (void) __attribute__((visibility ("hidden")));
void bar (void)
{
  foo ();
}
tail call GCC must emit a sequence which will work no matter how far foo
from bar's end is, if it is in the same shared library and output_mi_thunk
should emit the same. If this is impossible on certain arches,
then can_output_mi_thunk can just bail out and let the generic code handle
it.

> However, it can be seen that the thunk follows the function.  As a result,
> we can't be certain that a pc-relative branch will be able to reach the
> start of the function.  It would be better to have the thunk just before the
> function if possible.

How would it help? You can have many thunks, so if the pc-relative branch
is severely limited, you can as well not be able to branch accross the
other thunks.

	Jakub

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2003-06-26  7:50 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-06-25 16:51 [PATCH] Make calls in virtual thunks local if possible John David Anglin
2003-06-25 21:47 ` Jason Merrill
2003-06-26  7:50 ` Jakub Jelinek

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