This is the mail archive of the gdb-patches@sources.redhat.com 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]

Re: [RFA] Debug info detection.


Andrew Cagney wrote:
Hi all,
The attached patch adds new function cfi_have_unwind_info() that I'll use for detection, whether a given function has a dwarf2 unwind info (from .eh_frame or .debug_frame) or not. I'll use it in the upcomming x86_64_frame_p() to detect which set of unwind functions should be returned for a given frame.

Your comment about x86_64_frame_p() makes me wonder if you're going in the right direction.


Looking at the d10v, you'll see:

frame_unwind_append_predicate (gdbarch, d10v_frame_p);

For the x86-64, since it wants to also use dwarf2cfi and dwarf2eh, I'd expect to see something like:

  /* Try for a true CFI frame first.  If that fails, fall back to
     a .eh_frame info.  */
  frame_unwind_append_predicate (gdbarch, dwarf2cfi_frame_p);
  frame_unwind_append_predicate (gdbarch, dwarf2eh_frame_p);

  /* Finally, and as a last resort, use a prologue based unwinder.  */
  frame_unwind_append_predicate (gdbarch, x86_64_frame_p);

For now I have...


const struct frame_unwind *
x86_64_frame_p (CORE_ADDR pc)
{
  struct frame_unwind *unwind_cfi = NULL;
  struct frame_unwind *unwind_asm = &x86_64_asm_frame_unwind;
  struct frame_unwind *unwind_sigtramp = &x86_64_sigtramp_frame_unwind;
  char *name;

  find_pc_partial_function (pc, &name, NULL, NULL);
  if (gdbarch_pc_in_sigtramp (current_gdbarch, pc, name))
    return unwind_sigtramp;
  else if (cfi_have_unwind_info (pc))
    return unwind_cfi;   /* Returns NULL here...  */
  else
    return unwind_asm;
}

I.e. I'll handle sigtramps and non-CFI functions via the new way and fall back to old methods for CFI functions. That's because the CFI unwinder works quite well and I don't need to change it now, but backtrace through sigtramps doesn't work almost at all, and backtrace from non-cfi functions works only with my uncommitted hack. Both of these cases must be solved.

While I'm sure that splitting dwarf2cfi and dwarf2eh is logical, having

Why should we have different ways for unwinding with information taken from .debug_frame (is that what dwarf2cfi should be for?) and from .eh_frame (dwarf2eh)? Both of these sections provide the same data and the only different bits are in their parsing...


separate x86_64_frame_p() that only implements traditional prologe based unwind is correct.

Can I suggest starting from the other end - a new file dwarf2cfi-frame.[hc] and then moving in from there? The dwarf2expr.[hc] code was recently added and that was ment to superseed much of dwarf2cfi.c.

As I said higher - I'm doing this to solve backtrace for non-cfi frames. Rewriting the CFI engine is not my priority right now.


Michal Ludvig
--
* SuSE CR, s.r.o     * mludvig at suse dot cz
* (+420) 296.545.373 * http://www.suse.cz


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