[Dwarf-Discuss] how to find local variable stored in register

Daniel Berlin dberlin@dberlin.org
Tue Feb 5 19:13:32 GMT 2008


On Feb 5, 2008 2:01 PM, Jim Blandy <jimb at red-bean.com> wrote:
> On Feb 4, 2008 4:27 PM, Michael Eager <eager at eagercon.com> wrote:
> > Frank Ch. Eigler wrote:
> > > Hi -
> > >
> > > On Mon, Feb 04, 2008 at 03:19:43PM -0800, Michael Eager wrote:
> > >> Frank Ch. Eigler wrote:
> > >> [...]
> > >>>> Suppose this foo() funciton call another function, then this
> > >>>> register value will get stored in stack before invoking the function
> > >>>> call.
> > >>> A truthful compiler will add extra location records for this variable
> > >>> for the time (PC ranges) when its value is on the stack.
> > >> DWARF does not describe where variables are saved as result of a
> > >> function call.  This is specified by the processor ABI.
> > >
> > > A close reading of the original posting shows ... "before invoking the
> > > function call" ... that is during the function call setup instructions
> > > within the *caller*.  DWARF should indeed describe the saved location
> > > of the variable in these regions AFAIK.
> >
> > The register is stored as part of the calling convention.
> > DWARF does not duplicate information contained in the ABI
> > specification.
>
> The ABIs I have read say which registers' values a function must
> restore before it returns to its caller, and which registers a
> function is free to trash.  Some ABIs specify where the caller must
> save registers in the former class, but many ABIs do not; as long as
> the registers are restored somehow by the time control returns to the
> caller, the ABI is satisfied.
>
> In the case of registers saved by the caller, I've never seen an ABI
> specify where the caller must save them.  In such a case, there's
> really no way for a consumer to find those variables while there are
> younger function calls in progress, so I would hope a DWARF producer
> would provide location lists to cover the call sites.

In addition to Jim's point, there are also a number of valid
optimizations like interprocedural register allocation that will
either change which registers arguments are in, etc, or not save them
at all, so the processor ABI can't be relied upon.
One would hope a compiler would describe these in DWARF.




More information about the Dwarf-discuss mailing list