Re: [PATCH] Make calls in virtual thunks local if possible

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> On Sun, Jul 13, 2003 at 07:56:56PM -0400, John David Anglin wrote:
> > I am still of the opinion that this is dangerous when the local symbol
> > is an alias for a weak symbol.  At least on the PA, this creates serious
> > problems in the handling of function descriptors.
> 
> Why would you be creating a function descriptor for the local symbol?

Well originally, the jump from a thunk was not to a local symbol.
This is still the case under hpux.  If the jump is done as a pc-relative
or similar jump, the linker inserts a stub between the thunk and function.
Under hpux, the stub inserts the return pointer into the frame.  Since a
thunk has no frame, the second stub clobbers the return pointer set by the
first.  The only way to avoid this was to use a function descriptor and
jump directly to the function bypassing the stub.

Jakub's patch changed the target function from global to local under
hppa-linux (i.e., support for ASM_OUTPUT_DEF).  The above branch technique
broke because the linker can't handle a function pointer relocation to a
local symbol in a linkonce section that isn't included in the final output.
I'm still not certain if this is something that the linker should be able
to handle but it's tricky because the relocation information for the
function descriptor doesn't contain information as to the section that
a local symbol relocation refers to and whether it has been deleted.

Up to this point, we always were using function descriptors for
support of long calls and jumps from thunks on hppa-linux, even if they
were to local symbols.  Jakub's patch forced us to change to using
pc-relative calls when the call is to a local symbol.  This is a bit of
a mine field on the PA as different treatment is required for hppa-linux,
hppa-hpux (GAS and HP assembler), and hppa64-hpux, particularly for long
calls.  GAS and HP ld have known problems with certain relocations that
we have to work around.

So, in short, we were using function descriptors because of the hpux
problem, and various assembler and linker issues.  In the case of hpux,
there still isn't any other alternative.

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