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

Simon Marlow simonmar at microsoft.com
Wed Feb 14 05:30:22 EST 2001 

Hi Andy,

I don't have access to the HP box I built the binaries on at the moment,
so unfortunately I can't investigate right now.  Your analysis looks
sound, but like you I'm mystified why we're only now discovering the
problem.  Here's one clue: we always pass -static to the C compiler (but
not the linker, I think) on HPUX.

A bit of background: the JMP_ macro is used for every tail-call, that is
most basic blocks will end with a JMP_ instruction.  It is therefore not
the best place (in fact, probably the worst place) to be adding
instructions :-(

However, I'll glady commit your change to JMP_ on HPUX if it fixes your
problems - actually we're very grateful to have someone working on this!

Have you tried building the CVS sources, BTW?  It'd be nice if we had a
working HPUX port for the forthcoming release.

Cheers,
	Simon

> Having tried to build 'happy' with the version of GHC I have 
> and having
> discovered the GHC system libraries also depend on JMP_, I'm 
> inclined to
> think the only "safe" solution is to keep the "if". I can think of no
> solution to this; other than enforcing a linking method since 
> without a
> check one must guarantee all compiled modules make the same 
> assumptions
> about the environment, and that environment is present.
> 
> I'll leave it to you to choose what you wish to do about this.
> 
> Kind Regards and thanks for your help,
> Andy.
> 
> > -----Original Message-----
> > From: BENNETT,ANDY (HP-Unitedkingdom,ex1) 
> > Sent: 12 February 2001 03:24
> > To: 'Simon Marlow'; BENNETT,ANDY (HP-Unitedkingdom,ex1);
> > glasgow-haskell-bugs at haskell.org
> > Subject: RE: "Hello World" program core dumps with GHC 
> 4.08.1 on HPUX
> > 10.2 0
> > 
> > 
> > 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:simonmar at microsoft.com]
> > > > > Sent: 08 February 2001 04:23
> > > > > To: BENNETT,ANDY (HP-Unitedkingdom,ex1);
> > > > > glasgow-haskell-bugs at haskell.org
> > > > > 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
> > > > > Glasgow-haskell-bugs at haskell.org
> > > > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
> > > > > 
> > > > 
> > > 
> > > _______________________________________________
> > > Glasgow-haskell-bugs mailing list
> > > Glasgow-haskell-bugs at haskell.org
> > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
> > > 
> > 
>

More information about the Glasgow-haskell-bugs mailing list