RE: "Hello World" program core dumps with GHC 4.08.1 on HPUX 10.2 0

[BENNETT,ANDY (HP-Unitedkingdom,ex1)]

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 indirection, we're trying to get the 
> real address
> of the function on the stack.  
> 
> If you feel like investigating further, we'll be happy to incorporate
> any patches you come up with - unfortunately we're a bit 
> short on spare
> brain cycles here at the moment, with all attention diverted 
> to getting
> a GHCi release out ASAP.
> 
> Cheers,
>       Simon
> 
> _______________________________________________
> Glasgow-haskell-bugs mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
> 

_______________________________________________
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs