On Sat, 2014-01-18 at 21:53 +0100, Jan Kratochvil wrote:
On Sat, 18 Jan 2014 21:25:51 +0100, Mark Wielaard wrote:
> I don't think it is coincidence that split-stack would work. I believe we
> don't assume anything about the stack values and so it should work as
> expected since DWARF is expressive enough to describe it.
OK, so the patch can also already implement the GDB logic:
That is not very pretty. Lets just make sure unwinding works normally in
all cases, so we don't need such hacks.
> Using different stacks seems like a valid execution model and
> that is also used by things like sigaltstack.
sigaltstack can be handled by permitting arbitrary CFA adress change only
during signal frames.
That seems backwards. We shouldn't need to list all "allowed" contexts
for CFA changes. CFA changes between frames is normal. We just need to
detect bad changes like when the CFA or SP plus PC equals a previous
> We could use the PC combined with the CFA or SP as frame
> both are equal to the values in the previous frame then the unwind stack
> frame is corrupted.
That will not work for endless backtraces looping over >= 2 frames.
Yes, given that you don't have a defined ordering for the CFA values.
You could check all previous frames to check for duplicate values. But
that seems wasteful given that backtraces can be pretty deep. Just
checking the last frame will probably catch most bad call stacks.
> Another question is whether it is guaranteed that the CFA is
> always defined. I think the standard says an activation doesn't need
> to have a CFA defined. If not, then we probably should use the value
> of the SP register instead.
It depends on whether elfutils should support any hypothetical case or whether
the real world cases are sufficient. I am not aware of CFIs not defining CFA.
If there happen some it can be always fixed.
elfutils should support programs using the ELF and DWARF spec in
reasonable ways, plus commonly used GNU toolchain extensions. I don't
know whether the CFA is always defined, that is why I asked. But it
seems reasonable to expect it not always being defined. When an
architecture uses a link register and passes arguments and the return
values through registers then when a leaf function doesn't use any local
stack values then it doesn't seem necessary for example. At least that
is how I read the spec.
> The problem with using the SP value is that it is architecture
> we could define the register value through ebl.
Right, that's why SP was not used in that patch.
Lets see whether we need it or not.