Hi Simon,
I've had another e-mail back relating to this HP-UX linker / Procedure Label
thing, and apparently the behaviour I describe has been with HP-UX since
version 8.0, getting on for about for about ten years or so.
So, it is probably safe to assume the PLT extra indirection behaviour if any
shared library is linked, and ignore the indirection for archive only links.
However, the question still remains, why does your 'hsc' executable work
when it clearly has shared libraries. Do you use a linker other than HP's?
Are there other users of the HP-UX version?
Regards,
Andy.
That's great info, thanks. I think I'll paste this message into the
code :-)
Is there any way to detect at compilation time which scheme
we should be
using? Presumably switching the JMP to use an indirection will break
GHC on older versions of HPUX.
Cheers,
Simon
Thanks for the feedback Simon,
I've been digging a little further into the problem of how
HP-UX does
dynamic procedure calls. My solution in the last e-mail
inserting an extra
'if' statement into the JMP_ I think is probably the best
general solution I
can come up with. There are still a few problems with it
however: It wont
work, if JMP_ ever has to call anything in a shared library,
if this is
likely to be required it'll need something more elaborate. It
also wont work
with PA-RISC 2.0 wide mode (64-bit) which uses a different
format PLT.
I had some feedback from someone in HP's compiler lab and
the problem
relates to the linker on HP-UX, not gcc as I first suspected.
The reason the
'hsc' executable works is most likely due to a change in
'ld's behaviour for
performance reasons between your revision and mine.
The major issue relating to this is shared libraries and
how they are
implented under HP-UX. The whole point of the Procedure Label
Table (PLT) is
to allow a function pointer to hold the address of the
function and a
pointer to the library's global data lookup table (DLT) used
by position
independent code (PIC). This makes the PLT absolutely
essential for shared
library calls. HP has two linker introduced assembly
functions for dealing
with dynamic calls, $$dyncall and $$dyncall_external. The
former does a
check to see if the address is a PLT pointer and dereferences
if necessary
or just calls the address otherwise; the latter skips the
check and just
does the indirect jump no matter what.
Since $$dyncall_external runs faster due to its not having
the test, the
linker nowadays prefers to generate calls to that, rather
than $$dyncall. It
makes this decision based on the presence of any shared
library. If it even
smells an sl's existence at link time, it rigs the runtime system to
generate PLT references for everything on the assumption that
the result
will be slightly more efficient. This is what is crashing GHC
since the
calls it is generating have no understanding of the procedure
label proper.
The only way to get real addresses is to link everything
archive, including
system libraries, at which point it assumes you probably are
going to be
using calls similar to GHC's (its rigged for HP's +ESfic
compiler option)
but uses $$dyncall if necessary to cope, just in case you aren't.
Kind Regards,
Andy.
-Original Message-
From: Simon Marlow [mailto:[EMAIL PROTECTED]]
Sent: 08 February 2001 04:23
To: BENNETT,ANDY (HP-Unitedkingdom,ex1);
[EMAIL PROTECTED]
Subject: RE: "Hello World" program core dumps with GHC
4.08.1 on HPUX
10.2 0
I'm not sure whether I'm doing something wrong, but I've just
downloaded the
HPUX 4.08.1 binary distribution of GHC and have installed it
with GCC 2.95.2
(downloaded from HPUX porting site) along side it. I'm
running these on HPUX
10.20.
I seem to recall having some trouble with 2.95.2 on HPUX.
I think the
port was buit with 2.7.2.1.
It goes into the 'if' statement and hence the top element of
Sp becomes a
pointer to __init_Prelude(). It then tries to call this by
reading Sp's top
element and then goes to that address. This would be fine
except that what
is really placed on Sp by the assignment is a pointer to the
function's PLT
entry which has (function address, DLT pointer) pairs for
each function. The
"goto" is just doing a simple vectored branch into the table
rather than
using its entries to find the true address and jumping to that.
Hmm. I also vaguely remember having some trouble along these
lines too,
but I thought it was fixed in 4.08.1 (and I don't know much
about HPUX
dynamic linking I'm afraid).
Your analysis looks right - indeed the code is supposed to
be jumping
direct to the function, and the PLT entry is getting in the
way. Rather
than jump through the
