Opened 13 years ago

Closed 12 years ago

Last modified 48 years ago

#290 closed bug (Fixed)

amd64: adjustor creation possibly buggy

Reported by: aanno Owned by: nobody
Priority: normal Milestone:
Component: None Version: None
Keywords: Cc:
Operating System: Architecture:
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


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,  
I'm not sure if this is a bug because amd64 is not 
officially supported. 

Change History (14)

comment:1 Changed 13 years ago by wthaller

Logged In: YES 

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 

comment:2 Changed 13 years ago by ggd

Logged In: YES 

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 :-) 

comment:3 Changed 13 years ago by aanno

Logged In: YES 

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. 

comment:4 Changed 13 years ago by wthaller

Logged In: YES 

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:5 Changed 13 years ago by aanno

Logged In: YES 

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 
From this it is difficult for me to see any BaseReg joining 
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... 

comment:6 Changed 13 years ago by simonmar

Logged In: YES 

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:7 Changed 12 years ago by juhp

Logged In: YES 

I tried ghc-6-4-branch to test this, but it seems the changes
have not been merged there yet.

comment:8 Changed 12 years ago by juhp

Logged In: YES 

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:9 Changed 12 years ago by juhp

Logged In: YES 

Testing more carefully today with patched ghc-6.4 instead
(if it should make difference) I seeing segfaults with some
wx samples demos.  However I'm not certain if this is a
ghc, wxhaskell, or even wxwidgets issue yet.

comment:10 Changed 12 years ago by juhp

Logged In: YES 

(Well fwiw all gtk2hs-0.9.7/demos segfault for me too.)

comment:11 Changed 12 years ago by simonmar

Logged In: YES 

Re-opened, and moved to bugs.

comment:12 Changed 12 years ago by juhp

Logged In: YES 

Or should I open a new bug for the segfaulting? :)

comment:13 Changed 12 years ago by simonmar

Summary: amd64: adjustor creation not supportedamd64: adjustor creation possibly buggy
Logged In: YES 

No, I've changed $(subject)

comment:14 Changed 12 years ago by simonpj

Status: assignedclosed
Logged In: YES 

It's working fine now... (claim; yell if not)
Note: See TracTickets for help on using tickets.