Re: Data con names in the debugger

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