RE: Hello World program core dumps with GHC 4.08.1 on HPUX 10.2 0
Hi 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); [EMAIL PROTECTED] 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:[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
Re: Missing *.h files
I just installed ghc-4.08.2 on a WinNT system. When I compile Hello World with -O or -prof -auto-all ghc misses a lot of *.h files (see attached log files). Note to those who didn't see the attachments: all the missing includes are from the standard C library. What can I do? Set your Cygwin system up properly. gcc is not finding the standard includes. Try compiling C hello world first. -- http://sc3d.org/rrt/ "In 1727, Helen Morrison, a lonely spinster, became the first woman to place a Lonely Hearts advertisement. It appeared in the Manchester Weekly Journal. The mayor promptly committed her to a lunatic asylum for four weeks." - The People's Almanac #2 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Segmentation fault in program
The problem is indeed that the wrong __init_Foo is being passed to startupHaskell. The Haskell part of your program consists of two modules, Convert and ConvertProxy (the latter is generated by H/Direct). ConvertProxy imports Convert, and is therefore the "topmost" module in the program. To fix the GC problems, you must pass __init_ConvertProxy rather than __initConvert to startupHaskell. Sorry about the lack of documentation about this, hopefully we'll rectify that before the next release. Cheers, Simon -Original Message- From: T.J. Brown [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 13, 2001 4:10 PM To: Simon Marlow Subject: RE: Segmentation fault in program I believe I'm passing the correct __init_Foo unless I'm confused. Attached is the code. My ultimate goal here is to be able to pass streams of data from a C program to a Haskell function for processing. If there is a better way to do this than what I'm doing, please let me know. Thanks, T.J. --- Simon Marlow [EMAIL PROTECTED] wrote: GC problems sometimes result from the wrong __init_Foo being passed to startupHaskell. The symbol you pass in must relate to the topmost module in your program; all other modules must be directly or indirectly imported by the topmost module. If you're sure this is the case, could you send me the code and I'll take a look. Cheers, Simon -Original Message- From: Sigbjorn Finne [mailto:[EMAIL PROTECTED]] Sent: Monday, February 12, 2001 8:07 PM To: T.J. Brown Cc: [EMAIL PROTECTED] Subject: Re: Segmentation fault in program I'm able to reproduce this here too -- forwarded to glasgow-haskell-bugs; I'm no longer involved debugging GHC bits. --sigbjorn - Original Message - From: "T.J. Brown" [EMAIL PROTECTED] To: "Sigbjorn Finne" [EMAIL PROTECTED] Sent: Monday, February 12, 2001 19:21 Subject: Re: Segmentation fault in program After making the changes suggested below and updating the GHC driver script to fix the -no-hs-main bug, my program will successfully complete when processing a small amount of data. When processing larger amounts of data, however, it will crash with a segmentation fault or print "EVACUATED object entered". If I increase the size of the heap with "+RTS -Hsize" the program will complete successfully. It doesn't seem like the garbage collector is doing the right thing. Is there something I need to do to enable the garbage collector to free memory between subsequent calls to the my Haskell function (Convert)? Thanks, T.J. --- Sigbjorn Finne [EMAIL PROTECTED] wrote: Hi, your converttst.c contains the following decl: extern void startupHaskell (int argc, char* argv[], void* rootMod); void* __init_Main; That won't work, as the root module argument needs to point to something valid. Rewrite it to: extern void startupHaskell (int argc, char* argv[], void* rootMod); extern void* __init_Convert; and substitute __init_Main with __init_Convert wherever it is used in the C code. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Segmentation fault in program
The problem is indeed that the wrong __init_Foo is being passed to startupHaskell. No, that's not it. I've been able to repro this with __init_ConvertProxy too - did you test it? (This is with 4.08.1 on a Win2k box.) --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Hello World program core dumps with GHC 4.08.1 on HPUX 10.2 0
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); [EMAIL PROTECTED] 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,
RE: Segmentation fault in program
The problem is indeed that the wrong __init_Foo is being passed to startupHaskell. No, that's not it. I've been able to repro this with __init_ConvertProxy too - did you test it? (This is with 4.08.1 on a Win2k box.) Yes, I did, and was able to demonstrate a crash which went away when I changed __init_Convert to __init_ConvertProxy (with 4.08.2, but not on a Win2k box). Perhaps there's something else going on, I'll take a look on Win2k. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
