Right now, DEBUGGER only turns on the address->symbol mapping in the linker. I
don't think we really need an option here; in practice it'll always be on
anyway. It isn't likely that anyone will want to build GHCi without debugging
support.
Cheers,
Simon
Andy Gill wrote:
To understand, this functionality is only available under GHCi built code?
We need a wiki table, summarizing the various options and ways... Ahh
we do have one,
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Config
Can someone that knows what's what add infomation about the debugger
options
and flags used inside the RTS? Thanks.
AndyG
On Dec 18, 2006, at 4:14 AM, Simon Marlow wrote:
Simon Peyton-Jones wrote:
I saw that Ian committed your patches -- great!
Concerning the recovery of DataCon names, you write "The closure viewer
obtains the heap address of a Haskell value, find out the address of
its
associated info table, and trace back to the DataCon? corresponding
to this
info table. This is possible because the ghc runtime allocates a
static info
table for each and every datacon, so all we have to do is extend the
linker
with a dictionary relating the static info table addresses to a
DataCon?
name. Moreover, the ghci linker can load interpreted code containing
new data
or newtype declarations. So the dynamic linker code is extended in
the same
way."
Isn't there a simpler way to do this: just include the DataCon name
in the
info table of the data con. Of course that makes every (debuggable)
binary a
bit bigger, but so does all the breakpoint stuff.
Maybe. Doing this just for datacons wouldn't be so bad in terms of
bloat, and it'll be necessary anyway if we're using the systems
dynamic linker rather than the RTS linker, which is the case when
using shared libraries. The system dynamic linker can't in general
map addresses back to symbol names.
Pepe: while browsing the code, I noticed you're using an association
list for the AddressEnv - it would be better to use a FiniteMap here
(or maybe even a UniqFM).
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
