> >>> 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.) 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 _______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
