SourceForge has been redesigned. Learn more.
Close

#366 amd64: adjustor creation possibly buggy

closed-fixed
nobody
None
5
2005-07-06
2005-01-06
aanno
No

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.

Discussion

  • Wolfgang Thaller

    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.

     
  • Wolfgang Thaller

    • priority: 5 --> 3
     
  • Saša Janiška

    Saša Janiška - 2005-01-08

    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

     
  • aanno

    aanno - 2005-01-20

    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

     
  • Wolfgang Thaller

    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.

     
  • aanno

    aanno - 2005-03-11

    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

    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...

    Cheers,

    aanno

     
  • Simon Marlow

    Simon Marlow - 2005-03-11
    • status: open --> closed
     
  • Simon Marlow

    Simon Marlow - 2005-03-11

    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!

     
  • Jens-Ulrik Petersen

    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.

     
  • Jens-Ulrik Petersen

    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. :]

     
  • Jens-Ulrik Petersen

    Logged In: YES
    user_id=139853

    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.

     
  • Jens-Ulrik Petersen

    Logged In: YES
    user_id=139853

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

     
  • Simon Marlow

    Simon Marlow - 2005-05-09

    Logged In: YES
    user_id=48280

    Re-opened, and moved to bugs.

     
  • Simon Marlow

    Simon Marlow - 2005-05-09
    • priority: 3 --> 5
    • status: closed --> open
     
  • Jens-Ulrik Petersen

    Logged In: YES
    user_id=139853

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

     
  • Simon Marlow

    Simon Marlow - 2005-05-10

    Logged In: YES
    user_id=48280

    No, I've changed $(subject)

     
  • Simon Marlow

    Simon Marlow - 2005-05-10
    • summary: amd64: adjustor creation not supported --> amd64: adjustor creation possibly buggy
     
  • Simon Peyton Jones

    • status: open --> closed-fixed
     
  • Simon Peyton Jones

    Logged In: YES
    user_id=50165

    It's working fine now... (claim; yell if not)

     

Log in to post a comment.