Re: [parisc-linux] Incompatibility of PIC and non-PIC

Re: [parisc-linux] Incompatibility of PIC and non-PIC

[Cary Coutant]

>Shared libraries work well, but we've got a bigger problem now.  Our
>PIC and non-PIC code models are mutually incompatible in a big way
>(due to the use of %r19 And, it seems, while it's fine if non-PIC
>can't be used in shared libraries, it's not all right if PIC can't be
>linked statically.
> ...
>For that matter how does 32-bit HP/UX solve this issue?

When the HP-UX linker is building an a.out, it converts any r19-relative 
references into dp-relative references by rewriting the instructions. It 
still creates a linkage table entry if necessary (i.e., it doesn't 
rewrite a DLT-indirect reference as a direct dp-relative reference), but 
the linkage table entries are accessed via the dp register instead of r19.

Re: [parisc-linux] Incompatibility of PIC and non-PIC

[Alan Modra]

On Tue, 12 Sep 2000, Cary Coutant wrote:

> >Shared libraries work well, but we've got a bigger problem now.  Our
> >PIC and non-PIC code models are mutually incompatible in a big way
> >(due to the use of %r19 And, it seems, while it's fine if non-PIC
> >can't be used in shared libraries, it's not all right if PIC can't be
> >linked statically.
> > ...
> >For that matter how does 32-bit HP/UX solve this issue?
> 
> When the HP-UX linker is building an a.out, it converts any r19-relative 
> references into dp-relative references by rewriting the instructions. It 
> still creates a linkage table entry if necessary (i.e., it doesn't 
> rewrite a DLT-indirect reference as a direct dp-relative reference), but 
> the linkage table entries are accessed via the dp register instead of r19.

That's not too bad a hack.  I took a different approach and generate
import stubs when PIC code is detected during a static link.  David, is
there some problem with this (or was this a very old email that Cary was
replying to)?

Alan Modra
-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] Incompatibility of PIC and non-PIC

[David Huggins-Daines]

Alan Modra <alan@linuxcare.com.au> writes:

> That's not too bad a hack.  I took a different approach and generate
> import stubs when PIC code is detected during a static link.  David, is
> there some problem with this (or was this a very old email that Cary was
> replying to)?

Very old email, I think.  I don't see a problem with the way we do it
either, though.  Half dozen of one, six of the other...

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

[parisc-linux] Incompatibility of PIC and non-PIC

[David Huggins-Daines]

Hi,

Shared libraries work well, but we've got a bigger problem now.  Our
PIC and non-PIC code models are mutually incompatible in a big way
(due to the use of %r19 And, it seems, while it's fine if non-PIC
can't be used in shared libraries, it's not all right if PIC can't be
linked statically.

The reason this comes up is that libgcc.a has to be built with -fPIC
since it gets linked into libc.so.  However libgcc.a is also getting
statically linked with the binary itself (the symbols are not exported
by libc.so, though I'm not sure if this is the correct behaviour or
not), and of course it has to get linked in for statically linked
things anyway.

The result is of course that anything which uses 'long long', like,
say, GCC, will crash.

How do other architectures solve this issue? (or do they just have
ABIs that let you mix PIC and non-PIC...)

For that matter how does 32-bit HP/UX solve this issue?

One potential solution is to use %dp as the data pointer across the
board (which would solve the problem of mixing PIC and non-PIC in
static binaries), and generate export stubs for shared library calls
which restore the old %dp value (which would solve the problem of
maintaining the non-PIC %dp, useless though it may be).

<thinking wishful="wishful">
  Another one is to ditch our ... ahem ... unique ABI, use function
  prologues instead, have a single global pointer and a single link
  register, and have PIC, function pointers and dynamic linking work
  the way $DEITY intended :-)
</thinking>

Of course that's a lot more work and would probably involve breaking
the published ELF standard for HPPA, such as it is, as well as
foregoing a lot of code sharing with the rest of the PA-RISC stuff in
gcc and binutils :-(

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.