Re: New BSD licensed debugger

From: Doug Rabson <dfr_at_rabson.org>
Date: Thu, 17 Sep 2009 13:03:40 +0100
On 16 Sep 2009, at 21:37, Andrew Cagney wrote:

> Wicked; the location code, in particular, is sick.  As you've noticed,
> this isn't rocket science; and good language choice does make life
> easier.

Indeed.

>
> Several things to consider.
>
> Rather than frame-base, I'd use CFA or call-frame-address found in
> .debug_frame or CFI when identifying frames (and determining if the
> frame changed such as for step).  In addition, since frameless
> functions don't modify the CFA (they don't use the stack) you'll want
> to be combining it with the function's address giving a
> FrameIdentifier

I will probably switch to using CFA for identifying stack frames. LLVM  
produces useless values for AT_frame_base - it really needs to  
generate a location list rather than just saying 'EBP'.

> (oh, and IA-64 has two stacks so ... :-)

I know it. I did the FreeBSD/ia64 port and it was fun :)

>
> The unwinder looks to be trying to simultaneously handle both
> high-level inline and low-level ABI (CFA) frames, an alternative
> approach is to keep them separate (decorator pattern works well here)
> having an abi-only chain and then above that a chain of higher-level
> possibly inline frames.

I have to think about that. Unwinding inlines was added fairly  
recently and I'm certainly open to suggestions for making it more  
useful.

>
> A non-polling implementation would make a long term goal - which
> requires a mechanism for simultaneously blocking on both process and
> i/o events - on linux, at least, this is still a rats nest of bugs.

I think some kind of async implementation will be useful down the line  
too, especially if anyone wants to write a GUI on top of this stuff.
Received on Thu Sep 17 2009 - 10:08:36 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:55 UTC