Re: The cost of stack traces

[Casey Marshall <csm at gnu dot org>]

On May 10, 2006, at 2:01 PM, David Daney wrote:

> Casey Marshall wrote:
> > Something I wanted to do in the DWARF reader I wrote (but never  
> > did,  since the patch wasn't accepted) was to cache *approximate*   
> > information about where to look for debug info for an address. So   
> > you'd have a range of PC values that would map to regions in   
> > the .debug_line section where you would find the debug info you  
> > were  looking for. That would probably help lookup times, at least  
> > in a  long-running application, and the map wouldn't need to  
> > contain too  much data.
> > The big slowdown, from what I can tell, is that you have to scan  
> > from  the very beginning of the debug info to find the address,  
> > and that  can be slow for huge libraries like libgcj. You could  
> > probably  optimize the hell out of this, by scanning a library  
> > just once and  building a good, approximate cache of where to look  
> > things up.
> > Shall I post my patch for this again? :-)
>
> I, for one, would like very much to see the patch again.
>
> What were the reasons that it was not accepted?

I seem to recall that since it didn't support anything bug 32-bit  
ELF, it was considered too limited. But, that limitation isn't  
inherent; you could build up the same framework for other  
architectures and formats.

I don't think it was a strong "no." It kind of just fell off the  
radar, and I had disappeared for a while at the time.

Attachment: PGP.sig
Description: This is a digitally signed message part