From this it is difficult for me to see any BaseReg joining

Feature Requests item #1097471, was opened at 2005-01-07 05:55 Message generated for change (Comment added) made by juhp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_id=8032 Category: None Group: None Status: Closed Priority: 3 Submitted By: Thomas Pasch (aanno) Assigned to: Nobody/Anonymous (nobody) Summary: amd64: adjustor creation not supported Initial Comment: Hello, when trying to use wxhaskell on ghc-6.2.2 on an amd64 (unregistered gentoo build) the following happend: $ ./a.out a.out: internal error: adjustor creation not supported on this platform Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ I'm not sure if this is a bug because amd64 is not officially supported. ---------------------------------------------------------------------- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-08 17:32 Message: Logged In: YES user_id=139853 Just naively replacing DsForeign.lhs and Adjustor.c with the current versions from cvs trunk seems to work well so far though. :-) [ At least I got wxhaskell samples running with them on ghc-6-4-branch. :] ---------------------------------------------------------------------- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-07 11:07 Message: Logged In: YES user_id=139853 I tried ghc-6-4-branch to test this, but it seems the changes have not been merged there yet. ---------------------------------------------------------------------- Comment By: Simon Marlow (simonmar) Date: 2005-03-11 18:19 Message: Logged In: YES user_id=48280 Sorry :-( I implemented this yesterday. It was too late for 6.4, though (it'll be in 6.4.1). If you're interested in the code, take a look at Adjustor.c in CVS. I had to do some delicate hacking to work around the calling convention on x86_64, but fortunately it isn't as tricky as the powerpc version. Thanks for looking at this, and sorry I stepped on your toes! ---------------------------------------------------------------------- Comment By: Thomas Pasch (aanno) Date: 2005-03-11 17:31 Message: Logged In: YES user_id=349837 OK, I'm trying this. First I tried to do it the very same way as in x86: pushing hptr and obscure_ret_addr to stack. Of course, this doesn't work out because x86_64 does use REGISTER for the first 6 (in) arguments/paramenters. Next I tried to get hptr as second/#2 and obscure_ret_addr as first/#1 REGISTER parameter, shifting all REGISTER by 2 (and pushing arguments #6 and #5) to stack. Of course this does not work because obscure_ret is the (faked) return address and should be on the stack. My main problem is that I don't understand what is the the second argument (BaseReg) of StgRun(StgFunPtr f, StgRegTable *basereg) in StgCRun.c . How is this used in x86??? For me x86 stack for _ccall in Adjustor.c looks like: ??? 2nd arg to called haskell land function ??? 1st arg to called haskell land function ??? obsolete_ret_addr hptr obscure_ret_addr the game. In other architectures (i.e. sparc) the in REGISTER are a shifted by 2 as well. But in this architecture you don't need the obscure_ret_addr stuff. The bottom line is the following: I understand ghc adjustor, x86, and x86_64 calling convention. BUT the x86 part concering the BaseReg is pretty undocumented. Perhaps someone could give me a hand being more verbose in what is needed in the x86_64 adjustor... Cheers, aanno ---------------------------------------------------------------------- Comment By: Wolfgang Thaller (wthaller) Date: 2005-01-21 07:29 Message: Logged In: YES user_id=566359 The StgFunPtr that is passed to createAdjustor is a pointer to a normal C function (using the standard C calling convention) that takes as it's first argument the StgStablePtr hptr, a second "dummy" argument of the same size that is ignored (this is to help the implementation for the x86 ABI), and then all the arguments that were passed from the constructor. Note that if you need to do something to the stack after the function returns (rather than just tail-calling the function), you should arrange for the function to return to some static piece of code (see obscure_ccall_ret_code for x86) rather than to the adjustor itself. This is because the function might deallocate the adjustor. ---------------------------------------------------------------------- Comment By: Thomas Pasch (aanno) Date: 2005-01-21 05:20 Message: Logged In: YES user_id=349837 OK, I will have a try on this. I sort of understand x86 and x86_64 abi at the moment. There is only one question left at the moment: After I jump to StgFunPtr (a StgFun?) what will happen? Is this (a) a normal C land function that will require its argument (StgStablePtr hptr) as a 1st argument of the "universal" calling convention OR (b) some other kind of magic (from what source code?) that will pop its argument from the stack? Any answer would be appreciated. aanno ---------------------------------------------------------------------- Comment By: Gour (ggd) Date: 2005-01-08 19:34 Message: Logged In: YES user_id=728695 Hi! Just to add it's important issue for me since it affects the general gui-availability for Haskell language on amd64 platform since gtk2hs bindings also depend on it. Pls. raise this priority a little bit - amd64 is really a very 'natural' platform for Haskell :-) Sincerely, Gour ---------------------------------------------------------------------- Comment By: Wolfgang Thaller (wthaller) Date: 2005-01-07 06:48 Message: Logged In: YES user_id=566359 Yes, this is just a "missing feature". A small piece of platform specific code (<50 lines) is required to get foreign import "wrapper" declarations to work, and wxhaskell uses them a lot. A volunteer who wants to fix this would need enough knowledge about assembly language in general to really understand a calling convention (literature on amd64's particular calling convention is available somewhere). Most of the amd64-specific details can be picked up on the job. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_id=8032