This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Detect infinite backtraces


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.
> http://gcc.gnu.org/wiki/SplitStacks#Debugging

OK, so the patch can also already implement the GDB logic:
	https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=ebedcab50d2c7699ced23f4cf4eae712c0a9ca40


> Using different stacks seems like a valid execution model and something
> that is also used by things like sigaltstack.

sigaltstack can be handled by permitting arbitrary CFA adress change only
during signal frames.  Although in practice on supported archs it does not
happen as original stack is always above the sigaltstack.


> We could use the PC combined with the CFA or SP as frame identifier. If
> 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.


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


> The problem with using the SP value is that it is architecture specific. But
> we could define the register value through ebl.

Right, that's why SP was not used in that patch.


Thanks,
Jan

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]