This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa:dwarf2] Use frame_unwind_address_in_block
- From: Elena Zannoni <ezannoni at redhat dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Fri, 18 Jul 2003 15:20:49 -0400
- Subject: Re: [rfa:dwarf2] Use frame_unwind_address_in_block
- References: <3F15DE03.9000104@redhat.com>
Andrew Cagney writes:
> Hello,
>
> This, finally, is the tweak to the dwarf2-unwind code, to use the
> frame's address-in-block, instead of the frame's PC to select the CFI
> info. Two test cases stop failing:
>
> 1gdb.base/corefile.exp: backtrace in corefile.exp FAIL PASS
> 2gdb.base/gdb1250.exp: backtrace from abort KFAIL PASS
>
> Ok for the mainline?
> Ok to pull something equivalent into 6.0 branch?
seems sane.
elena
>
> Andrew
> 2003-07-16 Andrew Cagney <cagney@redhat.com>
>
> * dwarf2-frame.c (dwarf2_frame_sniffer): Use
> frame_unwind_address_in_block, instead of frame_pc_unwind.
> (dwarf2_frame_cache): Ditto.
>
> Index: dwarf2-frame.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/dwarf2-frame.c,v
> retrieving revision 1.9
> diff -u -r1.9 dwarf2-frame.c
> --- dwarf2-frame.c 16 Jul 2003 22:29:13 -0000 1.9
> +++ dwarf2-frame.c 16 Jul 2003 23:13:29 -0000
> @@ -491,15 +491,12 @@
> done for "normal" frames and not for resume-type frames (signal
> handlers, sentinel frames, dummy frames).
>
> - We don't do what GCC's does here (yet). It's not clear how
> - reliable the method is. There's also a problem with finding the
> - right FDE; see the comment in dwarf_frame_p. If dwarf_frame_p
> - selected this frame unwinder because it found the FDE for the
> - next function, using the adjusted return address might not yield
> - a FDE at all. The problem isn't specific to DWARF CFI; other
> - unwinders loose in similar ways. Therefore it's probably
> - acceptable to leave things slightly broken for now. */
> - fs->pc = frame_pc_unwind (next_frame);
> + frame_unwind_address_in_block does just this.
> +
> + It's not clear how reliable the method is though - there is the
> + potential for the register state pre-call being different to that
> + on return. */
> + fs->pc = frame_unwind_address_in_block (next_frame);
>
> /* Find the correct FDE. */
> fde = dwarf2_frame_find_fde (&fs->pc);
> @@ -710,15 +707,11 @@
> const struct frame_unwind *
> dwarf2_frame_sniffer (struct frame_info *next_frame)
> {
> - CORE_ADDR pc = frame_pc_unwind (next_frame);
> - /* The way GDB works, this function can be called with PC just after
> - the last instruction of the function we're supposed to return the
> - unwind methods for. In that case we won't find the correct FDE;
> - instead we find the FDE for the next function, or we won't find
> - an FDE at all. There is a possible solution (see the comment in
> - dwarf2_frame_cache), GDB doesn't pass us enough information to
> - implement it. */
> - if (dwarf2_frame_find_fde (&pc))
> + /* Grab an address that is guarenteed to reside somewhere within the
> + function. frame_pc_unwind(), for a no-return next function, can
> + end up returning something past the end of this function's body. */
> + CORE_ADDR block_addr = frame_unwind_address_in_block (next_frame);
> + if (dwarf2_frame_find_fde (&block_addr))
> return &dwarf2_frame_unwind;
>
> return NULL;