Date: Thu, 17 Sep 2009 13:03:40 +0100 From: Doug Rabson <dfr@rabson.org> To: Andrew Cagney <andrew.cagney@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: New BSD licensed debugger Message-ID: <C9DCB50C-B9E5-473C-B24C-732D189C1CCF@rabson.org> In-Reply-To: <c51b944b0909161337j49f94882we5a4cef8973fbb08@mail.gmail.com> References: <c51b944b0909161337j49f94882we5a4cef8973fbb08@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C9DCB50C-B9E5-473C-B24C-732D189C1CCF>