The cost of stack traces

[Casey Marshall]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 478 bytes
Desc: This is a digitally signed message part
URL: <http://gcc.gnu.org/pipermail/java/attachments/20060510/5f7ac3b7/attachment.sig>