Re: [parisc-linux] Applications in 64 bits userspace

[Carlos O'Donell <carlos@baldric.uwo.ca>]

John,

> I can't answer that.  Presumably, HP funded the development.  Possibly,
> they were considering using the GNU linker but then decided to go with
> a different port.  I do most of my 64-bit testing now with the HPUX
> linker.  There were some rough edges in using the HP linker with GCC
> a few months ago but these have been resolved.

I get random email from people who've seen my libc-alpha postings, and
they want to know how to fix their busted gcc (hppa2.0w) + HPUX linker
compiles... looks like floating point loads and stores with bad 
relocations (the reason we disable fpregs in the rtld code for glibc).

> The HP linker is not compliant with the sysv ELF ABI in its handling
> of weak symbols.  Undefined weak symbols are supposed to resolve
> to a value of 0, and the linker is not supposed to search archive
> libraries for undefined weaks.  I tried hacking GNU ld to see if
> this could be fixed but this isn't possible since the dynamic loader
> has the same behavior.  Basically, weak symbols appear to behave
> like secondary definition symbols with the SOM runtime.  The lack
> of proper weak support impacts GCC thread support.

Ick! Okay, I see why the initial intent to transition toolchains was
made. Though it still probably kicks our arse in terms of performance.

> I presume you are talking about the implementation for lazy linking.
> I know the ia64 implementation of function descriptors differs from
> what is done for the 32-bit hppa ports.

See Lu's patch at:
http://sources.redhat.com/ml/libc-alpha/2003-04/msg00048.html

It's a unification effort to try get arches that use func. desc. onto
the same page... hopefully lockless lookups and lazy linking :)
 
> Ok.  I should note that the current 64-bit GNU ld doesn't know how
> to do a true static link.

How so? -static and -nostdlib and add all the bits yourself?
 
> I certainly agree with that plan.  64-bit code is always going to
> be slower than 32-bit code, so it shouldn't be used unless really
> needed.

It would still be a nice treat to get more testing on the 64-bit
compiler, and be able to run bigger apps on the bigger PARISC boxes once
they become available :)

Though, yes, the current plan is, without fail, in the order I feel like
fixing them today:
- make -k check passes
- function descriptor fixes
- TLS support
- Static 64-bit userspace

c.