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

[Robinson, Paul T NonStop]

Pedantic super-precision would have a serious cost in terms of the size
of the debug info.  One thing we've done is mark the "call statement" as
beginning at the start of parameter setup, not at the call instruction.
You can step into the call (at which point the callee's parameters and
variables are where the DWARF says they are) or step over the call to
the next statement (at which point the caller's parameters and variables
are where the DWARF says they are).  We do not view it as a goal to make
the DWARF 100% precise for every single instruction, because our users
don't spend a lot of time single-stepping at the instruction level.

That said, when a variable gets spilled to the stack we typically do
want to identify that point and indicate it in the DWARF.  These places
are not necessarily closely associated with calls; they can happen for
other reasons too.

A similar consideration occurs at the entrypoint of a routine; typically
you need to work your way past a few prolog instructions (allocate the
stack frame etc) before you really have defined locations for things;
and yet the DWARF will commonly tell you that a variable is in a given
location for the entire scope of the routine.  This is an entirely
reasonable compromise between accuracy and info size, mediated mainly
by usefulness.

--paulr

-----Original Message-----
From: dwarf-discuss-bounces at lists.dwarfstd.org [mailto:dwarf-discuss-bounces@lists.dwarfstd.org] On Behalf Of Frank Ch. Eigler
Sent: Tuesday, February 05, 2008 11:23 AM
To: Jim Blandy
Cc: Neeraj kushwaha; dwarf-discuss at lists.dwarfstd.org
Subject: Re: [Dwarf-Discuss] how to find local variable stored in register

Hi -

> > >> [...]
> > >>>> 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.

> [...]
> 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.

It's even worse than that.  Considering that DWARF does not identify
those spots in a caller where "function call setup" is going on - the
instructions before the actual call - a debuginfo consumer would have
no way of knowing when to switch to this hypothetical implicit
ABI-specified location for saved registers.  Like I said, a truthful
compiler would have to spell it out.

(BTW, this seems like a special case of live range splitting.)


- FChE
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss at lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org