Simon
That sounds like simpler indeed, thanks!
One disadvantage of the current solution is that it could add some
tiny overhead onto the RTS Linker. Your solution would improve on
this aspect too, assuming that there are no other implications
related to adding a new record to the info table structure.
I am not sure if the same idea could be applied to the dynamic
linker, I will look into it.
There would be a size increase, but it shouldn't really be
noticeable. Note that currently we don't instrument binaries with
breakpoints, only interpreted modules can be debugged.
I will be adding this to the TODO list.
Thanks for the feedback Simon, please don't hesitate to keep it coming.
pepe.
On 18/12/2006, at 9:42, Simon Peyton-Jones wrote:
Pepe
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.
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
