Re: [RFA] Debug info detection.

Michal Ludvig
2003-03-07T15:48:15Z

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@suse.cz
* (+420) 296.545.373 * http://www.suse.cz