On Fri, Dec 07, 2018 at 07:57:23AM -0800, Michael Eager wrote:
> On 12/07/2018 04:54 AM, Jakub Jelinek wrote:
> > On Fri, Dec 07, 2018 at 12:36:39PM +0000, David Stenberg via Dwarf-Discuss
> > wrote:
> >
> > For calls, we need to distinguish the locations that are valid in the caller
> > on the call instruction before the call instruction has been executed, then
> > locations that are valid while inside of the call and finally locations that
> > are valid after the call has returned.
>
> But the call instruction is atomic. There are not distinct PC locations
> within an individual call instruction.
The instruction itself is, but the invocation of the called procedure is
not.
> I know what the PC is before the call, I know what the
> return address is in the called routine, and I know what the PC is
> after the return. None of these addresses is in the middle of the call.
>
> Why not generate the label as the next address following the call?
Because there is some other code there and some other locations might be
valid at that point, but not during the call. E.g. something could live in
the register holding return value from the function, which won't be there
until the function returns. The labels can be:
.L0:
whatever1
.L1:
call foo
.L2:
whatever2
.L3:
and in .debug_loc etc., I can provide say one location description for the
range .L0 to .L1 (i.e. for instructions before the call
instruction, another one e.g. for .L1 to .L2-1, valid on the call
instruction, but not inside of the foo call, another one from .L2-1 to .L2,
valid after the call foo instruction is done but before the call returned
(i.e. inside of the foo call or whatever it calls) and finally .L2 to .L3
range which covers the instructions after the call.
The debug info consumers usually subtract one from the return address with
the exception of signal frames so that they locate something in the middle
of the call instruction rather than whatever is after it (there could be
e.g. a completely different function be there already, or completely
unrelated code e.g. for calls that never return).
Jakub
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
