[Bug python/19288] need a way to see if an address is covered by some existing object

["adinn at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=19288

--- Comment #10 from Andrew Dinn <adinn at redhat dot com> ---
(In reply to Pedro Alves from comment #9)
> On the unwinder sniffer ordering, we could maybe try only the Python
> unwinders just before falling back to the heuristic/prologue-parsing-based
> arch unwinders.  So if we have DWARF debug/unwind info for the current PC,
> we never consult the Python unwinders at all.  Would there be a use case
> where we'd want Python unwinders to override DWARF debug/unwind info?
> 
> Even then, I assume you'd still want to be able to determine whether a PC is
> within the objfile you care about, so that your Python unwinder sniffer can
> say "nope, not mine", and then gdb falls back to the arch prologue unwinder.
> I.e., we'd still need "a way to see if an address is covered by some
> existing object" even if the order of the frame sniffers is interrogated is
> changed.
> 
> Is that a good assumption?

First off, I think the problem with JITted code is that it is not associated
with an object file. JITted code gets written into an anonymously mapped data
segment. So, I don't think we can rely on any association between unwinders and
objfiles to limit when our python unwinders get employed.

I think Tom and I are both assuming (well, at least, I am) that putting our
python unwinders further down the chain will mean

  i) other standard unwinders will grab the problematic frames (such as level
== -1 frames)

  ii) frames with JITted code pcs will be recognised as such by those standard
unwinders and ignored -- so will eventually trickle down to the python
unwinders

That's perhaps a questionable hypothesis.

a) It may be that one or more of the standard unwinders operates a fine sieve
matching policy which might catch some JITted pcs. Those unwinders would have
to follow the python unwinders.

b) If we are really unlucky then we might also find that those are the
unwinders which handle the problematic frames.

So, it is probably worth trying to re-order the unwinders and see what happens
(one quick way to test this would be to give all sniffers a hard-wired priority
and keep the sniffer chains priority-ordered). If we hit problem b) then the
unwinders will have to become smarter and, probably also, have to be able to
access more details from the underlying frame  (e.g. its level) in order to be
able to get smarter.

-- 
You are receiving this mail because:
You are on the CC list for the bug.