headers
Simon Marlow | 1 Aug 2001 11:04
Picon
Favicon

RE: FFI and Control-C

> So, my questions are:
> 
>   1) Does anyone know what exactly happens when control-C is
>      pressed during foreign function evaluation?

Yes.  Two cases: if the program hasn't requested that Ctrl-C be trapped
(using the Posix library's installHandler), then the SIGINT handler just
sets a flag which causes the scheduler to kill all the running threads
and exit.  If the program is in a foreign call, then the scheduler won't
get to run until the foreign call returns.

If the program has installed a handler for SIGINT (which GHCi does),
then the SIGINT handler in the RTS sets a different flag.  The next time
the scheduler runs, it creates a new thread for the handler and puts it
on the run queue.  In the case of GHCi, the handler thread raises an
exception in the main thread, which is caught by the GHCi loop.  Again,
if the main thread is in a foreign call, none of this will happen until
the call returns.

>   2) Does anyone know how this can be controlled in a more
>      finegrained way?

We don't have a good solution for this at the moment.  Where possible,
don't do blocking foreign calls.  The threadWaitRead/threadWaitWrite
primitives can be used to avoid blocking if you know the file descriptor
that the foreign call is going to block on.

Cheers,
	Simon
(Continue reading)

Permalink | Reply | 0 comments |
headers
Malcolm Wallace | 1 Aug 2001 11:31
Picon

Re: help needed for adding isWHNF primop to 5.00.2

Andy writes:

> What I want is gdb for GHC :-) Perhaps another build (like profiling vs
> optimizer), and when you press ^C, the ghcdb> prompt comes up :-)

Hey, we already have pretty-much exactly that in nhc98.  :-)

> I wonder if the Cost Center Stack idea can be combined some debugging
> concepts, giving an approximation to a stack dump, and you can
> print (using a non evaluating print) the stack?

Hey, we already have pretty-much exactly that in nhc98.  :-)

The new improved Hat now has several different debugging tools.

    hat-stack		gives a stack dump
    hat-observe		shows some or all actual uses of a function (cf. HOOD)
    hat-detect		automated algorithmic debugging (cf. Freja)
    hat-trail		the classic redex-trails browser (cf. "old" Hat)

There are also "tunnels" between the latter three tools, so you can
for instance jump from a dodgy observation straight into an algorithmic
debugging session starting at the suspicious point.  hat-observe is
about the nearest thing to a gdb I can imagine in a lazy pure setting.

For you ghc junkies out there, yes we are currently developing a
compiler-independent version of Hat which should give you identical
tracing facilities in ghc as in nhc98, at least for the Haskell'98
language.  The port is very much in its early stages though, so if you
want to try the Hat tools out and give us your feedback on whether
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernard James POPE | 1 Aug 2001 11:46
Picon
Picon

adding isWHNF primop to 5.00.2 native code generator

Hi all,

More mind boggling questions on prim ops :)

I am happy with isWHNF that is implemented with:

   #define isHNFzh(r,a) r=(! closure_THUNK((StgClosure *)a))

I will re-write for the IO Monad later.

I want to mimic this behaviour in the native code
generator.

Sigbjorn gave me this suggestion, which is based on
DataToTagOp.

   \begin{code}
   primCode [res] IsHNF [arg]
      = let res'        = amodeToStix res
            arg'        = amodeToStix arg
            arg_info    = StInd PtrRep arg'
            word_32     = StInd WordRep (StIndex PtrRep arg_info (StInt (-1)))
            masked_le32 = StPrim SrlOp [word_32, StInt 16]
            masked_be32 = StPrim AndOp [word_32, StInt 65535]
   #ifdef WORDS_BIGENDIAN
            ty_info     = masked_le32
   #else
            ty_info     = masked_be32
   #endif
            not_a_thunk = StPrim IntEqOp [ StPrim AndOp [ty_info, StInt 0x10]
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Seward (Intl Vendor | 1 Aug 2001 12:09
Picon
Favicon

RE: adding isWHNF primop to 5.00.2 native code generator

| Sigbjorn gave me this suggestion, which is based on DataToTagOp.
| 
|    \begin{code}
|    primCode [res] IsHNF [arg]
|       = let res'        = amodeToStix res
|             arg'        = amodeToStix arg
|             arg_info    = StInd PtrRep arg'
|             word_32     = StInd WordRep (StIndex PtrRep 
| arg_info (StInt (-1)))
|             masked_le32 = StPrim SrlOp [word_32, StInt 16]
|             masked_be32 = StPrim AndOp [word_32, StInt 65535]
|    #ifdef WORDS_BIGENDIAN
|             ty_info     = masked_le32
|    #else
|             ty_info     = masked_be32
|    #endif
|             not_a_thunk = StPrim IntEqOp [ StPrim AndOp [ty_info,
StInt 0x10]
|                                          , StInt 0x0
|                                          ]
|                    -- ToDo: don't hardwire the value of 
| _THUNK from InfoTables.h
|             assign      = StAssign IntRep res' not_a_thunk
|         in
|         returnUs (\ xs -> assign : xs)
|    \end{code} 
| 
| 
| I get different results with the version using the C macro 
| and the native code version. In particular I get the wrong
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Marlow | 1 Aug 2001 12:28
Picon
Favicon

RE: adding isWHNF primop to 5.00.2 native code generator

>    \begin{code}
>    primCode [res] IsHNF [arg]
>       = let res'        = amodeToStix res
>             arg'        = amodeToStix arg
>             arg_info    = StInd PtrRep arg'
>             word_32     = StInd WordRep (StIndex PtrRep 
> arg_info (StInt (-1)))
>             masked_le32 = StPrim SrlOp [word_32, StInt 16]
>             masked_be32 = StPrim AndOp [word_32, StInt 65535]
>    #ifdef WORDS_BIGENDIAN
>             ty_info     = masked_le32
>    #else
>             ty_info     = masked_be32
>    #endif
>             not_a_thunk = StPrim IntEqOp [ StPrim AndOp 
> [ty_info, StInt 0x10]
>                                          , StInt 0x0
>                                          ]
>                    -- ToDo: don't hardwire the value of 
> _THUNK from InfoTables.h
>             assign      = StAssign IntRep res' not_a_thunk
>         in
>         returnUs (\ xs -> assign : xs)
>    \end{code} 

This code looks bogus - it is checking a bit in the info table, which
would have been correct when we used to store flags in the info table,
but that changed a while back.

closure_THUNK() works by getting the type field (i.e.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernard James POPE | 3 Aug 2001 07:05
Picon
Picon

RE: adding isWHNF primop to 5.00.2 native code generator

Hi all,

Hack alert!

I took Julian's advice and looked over the assembly output from
ghc.

In all the cases I tried, the info pointer in the closure header
pointed to the end of the info table. Although a comment in
ghc/includes/ClosureMacros.h worries me:

       "info pointer"    The first word of the closure.  Might point
                         to either the end or the beginning of the
                         info table, depending on whether we're using
                         the mini interpretter or not.  GET_INFO(c)
                         retrieves the info pointer of a closure.

Can someone please clarify when the info pointer will point to
the beginning or end of the table?

Basically I have assumed for the moment that it points to the end
of the table, as that is what some other code in ghc seems to 
assume.

This makes it easy (hack?) to find the "type" field of the info table,
its just the bottom (or top, depending on which way you look at it)
16 bits prior to the address that the info pointer contains. Essentially
dataToTag# gives you these bits. I don't think "dataToTag#" is a great
name for this primop, something like: closureType#, or classifyClosure#
might be better.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ashley Yakeley | 3 Aug 2001 10:46

Missing functions in GHC's RTS?

At 2001-08-03 00:41, I wrote (on the Haskell Cafe list):

>When I make a function generator with "foreign export dynamic", GHC spits 
>out stub files which it apparently then needs for the link. What are 
>these for?

OK, so I don't know what they are, but the link needs the _stub.o file. 
Unfortunately, the stub file includes these symbols:

rts_getWord8
rts_getWord16
rts_getInt16
rts_getInt64

...which do not appear to be in any library and indeed are not declared 
in RtsAPI.h, although corresponding rts_mk* functions are. This looks 
like a bug in GHC.

$ ghc -v
Glasgow Haskell Compiler, Version 5.00, for Haskell 98, compiled by GHC 
version 5.00
Using package config file: /usr/lib/ghc-5.00/package.conf
Hsc static flags: -static -fignore-interface-pragmas 
-fomit-interface-pragmas -fdo-lambda-eta-expansion -flet-no-escape

$ uname -a
Linux server 2.2.19pre17 #1 Tue Mar 13 22:37:59 EST 2001 i686 unknown

--

-- 
Ashley Yakeley, Seattle WA
(Continue reading)

Permalink | Reply | 501 comments |
headers
Sigbjorn Finne | 3 Aug 2001 18:33

Re: Missing functions in GHC's RTS?

That looks like an omission; I've checked in impls for
the missing getter routines.

--sigbjorn

----- Original Message -----
From: "Ashley Yakeley" <ashley <at> semantic.org>
To: "Haskell Cafe List" <haskell-cafe <at> haskell.org>; "GHC List"
<glasgow-haskell-users <at> haskell.org>
Sent: Friday, August 03, 2001 01:46
Subject: Missing functions in GHC's RTS?

> At 2001-08-03 00:41, I wrote (on the Haskell Cafe list):
>
> >When I make a function generator with "foreign export dynamic", GHC spits
> >out stub files which it apparently then needs for the link. What are
> >these for?
>
> OK, so I don't know what they are, but the link needs the _stub.o file.
> Unfortunately, the stub file includes these symbols:
>
> rts_getWord8
> rts_getWord16
> rts_getInt16
> rts_getInt64
>
> ...which do not appear to be in any library and indeed are not declared
> in RtsAPI.h, although corresponding rts_mk* functions are. This looks
> like a bug in GHC.
>
(Continue reading)

Permalink | Reply | 501 comments |
headers
Ashley Yakeley | 6 Aug 2001 02:33

GHC FFI Return Type Bug

Has anyone else come across this? I've only tried this with Word8 but I 
suspect this is a problem with all return types smaller than four bytes.

I've entered this as GHC bug #448104.
<http://sourceforge.net/tracker/index.php?func=detail&aid=448104&group_id=8
032&atid=108032>

Here's the C code:

extern "C"
	{
	unsigned char foo();
	}

inline void use(const char* s)
	{
	}

unsigned char foo()
	{
	const char* s = "";
	use(s);
	return 0;
	}

...and the Haskell looks something like this:

 foreign import foo :: IO Word8

do {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Seward (Intl Vendor | 6 Aug 2001 11:57
Picon
Favicon

RE: GHC FFI Return Type Bug

Hmm, we're looking at this.  However, I don't really know what
C is or is not supposed to do here.  Given

char fooble ( ... )
{
   return 'z';
}

on an x86, 'z' will be returned at the lowest 8 bits in %eax.
What I don't know is, is the C compiler obliged to clear the
upper 24 bits of %eax, or does that onus fall on the callee?
Also, I don't even know where to look for the specification of
details of the C calling conventions.  Anyone got a clue?

J

| -----Original Message-----
| From: Ashley Yakeley [mailto:ashley <at> semantic.org] 
| Sent: Monday, August 06, 2001 1:34 AM
| To: GHC List
| Subject: GHC FFI Return Type Bug
| 
| 
| Has anyone else come across this? I've only tried this with 
| Word8 but I 
| suspect this is a problem with all return types smaller than 
| four bytes.
| 
| I've entered this as GHC bug #448104. 
| <http://sourceforge.net/tracker/index.php?func=detail&aid=4481
(Continue reading)

Permalink | Reply | 2 comments |

Gmane