This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH] Make calls in virtual thunks local if possible
- From: Jakub Jelinek <jakub at redhat dot com>
- To: John David Anglin <dave at hiauly1 dot hia dot nrc dot ca>
- Cc: gcc-patches at gcc dot gnu dot org, binutils at sources dot redhat dot com
- Date: Thu, 26 Jun 2003 03:50:38 -0400
- Subject: Re: [PATCH] Make calls in virtual thunks local if possible
- References: <200306251546.h5PFkKQM006854@hiauly1.hia.nrc.ca>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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