Re: [parisc-linux] PIC code generation in gcc/binutils

Re: [parisc-linux] PIC code generation in gcc/binutils

[Cary Coutant]

>I was hoping to write up a preliminary ABI specification based on the
>64-bit ELF implementation on HP/UX, so I've been trying to find
>detailed specifications on how the ELF64 ABI actually works but so far
>have not come up with much information from HP's documentation.  The
>64-bit runtime architecture document has some useful information, but
>I suspect I'll have to look at the actual implementation to nail down
>the details.

As the HP-UX Runtime Architect, I'll be happy to answer any questions you 
may have on the runtime architecture. I realize that the 64-bit runtime 
architecture is weak in the dynamic loading area, but I'll try to make up 
for that by answering questions in this forum.


>One thing I am sure of is that if we try to follow the HP/UX ELF64
>specification for dynamic linking on 32-bit Linux we are going to be
>substantially different from other Linux/ELF platforms.  In
>particular, the handling of inter-module calls and function pointers,
>and the management of the GP, are done in a totally different way from
>all the other platforms I've encountered (i386, m68k, alpha).
>(i.e. inter-module calls are handled by another set of stubs, and GP
>management is done by the caller via the function descriptors, rather
>than by the callee with GPDISP and similar relocations)

The model used for PA-RISC is a a consequence of the segmented 
architecture, where the text and data segments are not adjacent. Since 
the PA-RISC sharing model is based on global virtual addresses, the text 
and data segment are loaded in separate quadrants of the address space so 
that the text can be shared and the data can be process-private. As a 
result, a procedure cannot materialize its own gp, since there is no 
fixed pc-relative offset between the text and data. This means that the 
caller must materialize the gp prior to the call, or as part of the call.

By the way, this model is also being used for IA-64. You may be able to 
leverage some of the work being done for ld.so on that platform.

It shouldn't really complicate the dynamic loader that much, though. A 
function pointer is still essentially a function pointer, and behaves the 
same as in the other model, even though it points to a 128-bit descriptor 
rather than an actual function. The linker needs to allocate a GOT entry 
for each import stub (aka "proxy") it creates, and attach a dynamic FPTR 
relocation to that GOT entry. The dynamic loader needs to create the 
function descriptor when it processes the FPTR relocation.

Lazy binding requires a bit of cleverness. We do it by dynamically 
creating lazy-binding stubs that load a module id and a PLT index into 
registers, then branch to a common bind-on-reference routine.


Cary Coutant
HP-UX Runtime Architect

Re: [parisc-linux] PIC code generation in gcc/binutils

[Ulrich Drepper]

Cary Coutant <cary@cup.hp.com> writes:

> Lazy binding requires a bit of cleverness. We do it by dynamically 
> creating lazy-binding stubs that load a module id and a PLT index into 
> registers, then branch to a common bind-on-reference routine.

We will have our own lazy-binding mechanisms (close to Sun's
approach).  So don't plan to bring this in.  You can live without it
for now.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: [parisc-linux] PIC code generation in gcc/binutils

[David Huggins-Daines]

Cary Coutant <cary@cup.hp.com> writes:

> The model used for PA-RISC is a a consequence of the segmented 
> architecture, where the text and data segments are not adjacent.

For what it's worth our ELF32 runtime conventions do not use
segmentation at all.  That is, in user space, %sr0 and %sr4 through
%sr7 are all set to the same space identifier.

This is in keeping with accepted practice on other 32-bit Linux
platforms where segmentation is used only to provide separate 4G
address spaces for the kernel and userland.

> As a result, a procedure cannot materialize its own gp, since there
> is no fixed pc-relative offset between the text and data. This means
> that the caller must materialize the gp prior to the call, or as
> part of the call.

I can see some advantages in this even with a non-segmented runtime
architecture - theoretically, having the GP be managed by the caller
rather than the callee should make intramodule calls in
position-independent code more efficient.  (I think so at least)

One thing I have not figured out is how the GP is "bootstrapped" in
the startup code for the dynamic linker itself - how does ELF64 on
HP/UX deal with this problem?

> By the way, this model is also being used for IA-64. You may be able to 
> leverage some of the work being done for ld.so on that platform.

Thanks for the tip... as it turns out, the author of the dynamic
linker support for GNU libc on IA-64 sits two cubes away from me, so
that should be quite helpful indeed :-)

> Lazy binding requires a bit of cleverness. We do it by dynamically 
> creating lazy-binding stubs that load a module id and a PLT index into 
> registers, then branch to a common bind-on-reference routine.

For the moment I am not going to worry about lazy binding at all,
though it is certainly a requirement in the future.

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

Re: [parisc-linux] PIC code generation in gcc/binutils

[Alan Modra]

On 24 Jul 2000, David Huggins-Daines wrote:

> Cary Coutant <cary@cup.hp.com> writes:
> 
> > The model used for PA-RISC is a a consequence of the segmented 
> > architecture, where the text and data segments are not adjacent.
> 
> For what it's worth our ELF32 runtime conventions do not use
> segmentation at all.  That is, in user space, %sr0 and %sr4 through
> %sr7 are all set to the same space identifier.

Hmm, I haven't been making this assumption in the elf32-hppa binutils
shared lib support.  If userland uses the same space id, then import
stubs can be simplified quite a bit, and there's no need for export stubs.

> This is in keeping with accepted practice on other 32-bit Linux
> platforms where segmentation is used only to provide separate 4G
> address spaces for the kernel and userland.

On parisc, doesn't a single space id limit your address space to 1G?

Alan Modra
-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] PIC code generation in gcc/binutils

[Matthew Wilcox]

On Tue, Jul 25, 2000 at 11:12:28AM +1000, Alan Modra wrote:
> On parisc, doesn't a single space id limit your address space to 1G?

that was what I thought too, but it turns out that the quarter of the
space which is addressed is the same as the top 2 bits of the data
register.  ie, if we were using 4 distinct spaces, we would see the
following usage pattern:

xx......
..xx....
....xx..
......xx

so using just one space register for the entire process doesn't affect us
at all.

http://devresource.hp.com/devresource/Docs/Refs/PA1_1/acd-17.html

is an authoritive source for this information:

"Only one fourth of the space is directly addressable by the base register
with short pointers and corresponds to the quadrant selected by the
upper two bits."

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] PIC code generation in gcc/binutils

[Matthew Wilcox]

On Tue, Jul 25, 2000 at 11:12:28AM +1000, Alan Modra wrote:
> On parisc, doesn't a single space id limit your address space to 1G?

that was what I thought too, but it turns out that the quarter of the
space which is addressed is the same as the top 2 bits of the data
register.  ie, if we were using 4 distinct spaces, we would see the
following usage pattern:

xx......
..xx....
....xx..
......xx

so using just one space register for the entire process doesn't affect us
at all.

http://devresource.hp.com/devresource/Docs/Refs/PA1_1/acd-17.html

is an authoritive source for this information:

"Only one fourth of the space is directly addressable by the base register
with short pointers and corresponds to the quadrant selected by the
upper two bits."

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] PIC code generation in gcc/binutils

[Cary Coutant]

>I realize that the 64-bit runtime 
>architecture is weak in the dynamic loading area, ...

By the way, I meant the documentation, not the runtime architecture 
itself!

Re: [parisc-linux] PIC code generation in gcc/binutils

[Cary Coutant]

>I can see some advantages in this even with a non-segmented runtime
>architecture - theoretically, having the GP be managed by the caller
>rather than the callee should make intramodule calls in
>position-independent code more efficient.  (I think so at least)

Yes, it does have that advantage, and we take advantage of it when we can 
determine at compile time that the callee is in the same load module.

>One thing I have not figured out is how the GP is "bootstrapped" in
>the startup code for the dynamic linker itself - how does ELF64 on
>HP/UX deal with this problem?

The kernel loader passes a "load info" record to the dynamic loader as 
the fourth parameter (after argc, argv, and envp). This record contains, 
among other things, the load addresses of the dynamic loader's text and 
data segments. The dynamic loader's startup code materializes its own gp 
based on the base address of its data segment.

-cary

[parisc-linux] PIC code generation in gcc/binutils

[David Huggins-Daines]

Hi Alan, other porters,

I'm at the point now (userland mostly works for me as does the 64-bit
toolchain) where I'd like to start working on the implementation of
ELF dynamic linking for hppa-linux.  Obviously the precondition for
this is a working PIC code model in GCC and binutils.

I was hoping to write up a preliminary ABI specification based on the
64-bit ELF implementation on HP/UX, so I've been trying to find
detailed specifications on how the ELF64 ABI actually works but so far
have not come up with much information from HP's documentation.  The
64-bit runtime architecture document has some useful information, but
I suspect I'll have to look at the actual implementation to nail down
the details.

One thing I am sure of is that if we try to follow the HP/UX ELF64
specification for dynamic linking on 32-bit Linux we are going to be
substantially different from other Linux/ELF platforms.  In
particular, the handling of inter-module calls and function pointers,
and the management of the GP, are done in a totally different way from
all the other platforms I've encountered (i386, m68k, alpha).
(i.e. inter-module calls are handled by another set of stubs, and GP
management is done by the caller via the function descriptors, rather
than by the callee with GPDISP and similar relocations)

This will potentially make implementing ld.so more difficult, and thus
I'm not sure how desireable it is to follow the 64-bit example; we
will never have to actually link and load HP/UX ELF binaries with our
native toolchain and dynamic linker, even when we do have support for
64-bit userland.

On the other hand following the ELF64 example *will* allow us to reuse
code (though the ELF64 PIC implementation in BFD appears to be still
somewhat incomplete) in binutils, so it looks like kind of a
binutils/ld.so tradeoff.

Thus I am playing a bit with adapting the ELF64 code to produce a
preliminary PIC-generating toolchain.  I don't, however, want to get
too far into this before knowing (a) what other people are working on,
and (b) what the implementation is going to look like.

Thoughts?

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