Re: Data con names in the debugger

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