[Dwarf-Discuss] Location list entries for caller-saved registers at time of call

[Michael Eager]

On 12/07/2018 08:38 AM, Cary Coutant 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.
>>
>> So?  The return address doesn't slowly creep through the call
>> instruction as the called procedure executes.
> 
> Jakub is correct. It's not that the return address creeps slowly
> through the call instruction -- it's that there are three distinct
> phases in the call:
> 
> 1: before the call (pc is at the call instruction)
> 2: during the call (pc is in the called function, and rp points to the
> instruction after the call)
> 3: after the call (pc is at the instruction after the call)
> 
> Before the call (1), the value is still live in %eax, so the range
> should include the address of the call instruction.
> 
> During the call (2), the value is unknown, because %eax is
> callee-save. As postulated, GCC is aware that unwinders will subtract
> 1 from the rp, so it knows that it can exclude this phase from the
> range list entry by subtracting one from the address of the next
> instruction. (It could just as easily used the address of the call
> instruction + 1.)

I think I see the difference in our viewpoints.

I believe that when the consumer (GDB in this case) unwinds the stack,
the PC should be at the return location.  If it evaluates the loclist
with this value, it will get the correct result.

GDB subtracts one to insure that the return PC is within the calling
function, so that it will find the debug data for the correct function.
That's fine.  It then uses this modified PC value to search the loclist,
which is (IMO) a bug.

> After the call (3), the value is still unknown. Setting the end of the
> range to the address of the instruction following the call would have
> covered this, but not the time during the call.
> 
> -cary
> 
> 

-- 
Michael Eager    eager at eagerm.com
1960 Park Blvd., Palo Alto, CA 94306