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