This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]