Re: [RFA] Debug info detection.

[Michal Ludvig <mludvig@suse.cz>]

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