This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug python/19288] need a way to see if an address is covered by some existing object
- From: "tromey at sourceware dot org" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Thu, 14 Apr 2016 18:12:55 +0000
- Subject: [Bug python/19288] need a way to see if an address is covered by some existing object
- Auto-submitted: auto-generated
- References: <bug-19288-4717 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=19288
--- Comment #14 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Pedro Alves from comment #13)
> > 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).
>
> Agreed, we need something like that.
>
> Seems like the order should then be:
>
> - The "Accurate unwinders"
>
> These would be the DWARF / x64 SEH based ones.
>
> - JIT unwinders
>
> Python/Guile unwind API unwinders, and also the C JIT-reader API unwinder,
> in jit.c.
>
> - Fallback prologue unwinders
There are two scenarios worth considering here.
One is, suppose there is an objfile without debuginfo. In this case,
it seems that the frame will be presented to my Python unwinder. However,
I already know my unwinder can't deal with this. So I would still
appreciate some way of finding out whether a given PC is in some objfile.
Simply moving the Python unwinder lower won't work because the prologue
unwinder might "make sense" of a JIT frame, even though it really can't.
The other scenario is speculative: if someone wrote a caching JIT that
wrote out object code and dlopened it in a later invocation. But I think
the above ordering suffices for that.
--
You are receiving this mail because:
You are on the CC list for the bug.