Re: [PATCH/i386newframe/RFC] DWARF CFI frame unwinder

Daniel Jacobowitz
2003-05-05T03:42:47Z

On Sun, May 04, 2003 at 11:35:27PM -0400, Andrew Cagney wrote:
> Mark, fyi,
>
> >+ case REG_SAVED_REG:
> >+ *optimizedp = 0;
> >+ *lvalp = lval_register;
> >+ *addrp = 0;
> >+ *realnump = DWARF2_REG_TO_REGNUM (cache->reg[regnum].loc.reg);
> >+ if (valuep)
> >+ {
> >+ /* Read the value from the register. */
> >+ frame_unwind_register (next_frame, *realnump, valuep);
> >+ }
> >+ break;
> >+
>
> Set *addrp to the register offset hack (Otherwize something mysterious
> fails. What? I don't remember).
>
> Using the frame obstack for memory looks right.
>
> >+static CORE_ADDR
> >+dwarf_frame_base_address (struct frame_info *next_frame, void
> >**this_cache)
> >+{
> >+ struct dwarf_frame_cache *cache = dwarf_frame_cache (next_frame,
> >this_cache);
> >+
> >+ return cache->cfa;
> >+}
>
> This isn't right. It should return DW_AT_frame_base. However, since
> dwarf2expr.c doesn't yet use these methods it doesn't [?] really matter.
> Only affects ``info frame''.

I don't think it should.

The frame's CFA is the basis for identifying the frame and locating
saved registers in the CFI. It is always present when you have CFI.

DW_AT_frame_base is the basis for locating saved variables and locals.
It is generally present when you have DWARF-2 debug info.

The two are not necessarily related. I don't remember how we settled
on providing DW_AT_frame_base. Possibly a debug info auxiliary to the
function symbol or to the block.

By the way, I don't remember something else I believe we've
discussed... Does each target that wants to use the CFI unwinder have
to add it in its gdbarch initialization?

--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer