Stack unwind details in gprofng

Stack unwind details in gprofng

[Vladimir Mezentsev]

As a follow on to the discussion on this at Cauldron 2022, we thought it
may be useful to explain our stack unwind in more detail. Please find
this below.

We are aware of more recent developments we may be able to leverage and
in any case are very open to suggestions for improvement.

Kind regards, Vladimir

PS All details can be found in 
binutils-gdb.git/gprofng/libcollector/unwind.c.


====== Our approach

The basic issue with our x86 stack unwind is that we don't know if we can
trust the frame-pointer register. So we walk instructions to find a return
instruction, at which point we know the return address is on the top of the
stack, etc.

This is a challenge when we encounter "jmp *(reg)" instruction, where
we are expected to jump to the (unknown-to-us) contents of a register.

Our "jmp_reg" code attempts to keep track of the context for such a jump,
deferring any handling of such a difficult case. We continue with other
contexts, hoping that some other walk will take us to a return instruction.

If no other walk helps, we return to "jmp_reg" contexts.

While we don't know the jump target, it is possible that the bytes 
immediately
following the jmp_reg instruction represent one possible target, as 
might be
the case when a "switch" statement is compiled.

Unfortunately, the bytes following a "jmp_reg" instruction might instead 
be a
jump target from somewhere else -- execution might never "fall through" 
from the
preceding "jmp_reg". Those bytes might not even be instructions at all. 
There
are many uses of jmp_reg instructions beyond just compiling switch 
statements.

If the above approach fails and we did not find a return instruction, we 
try to
use the frame-pointer register.


On aarch64 we use dladdr() from libdl.so.  We're looking to at Paul Brook's
implementation 
(https://github.com/gcc-mirror/gcc/blob/master/libgcc/config/arm/unwind-arm.c)