Re: [Libunwind-devel] Reg: Libunwind with threads lib and system calls

[Sasikanth]

Arun,

  I clearly told stack trace not working because of invalid frame pointer ...without a proper frame pointer unwind not able to unwind the stack and asked her does  this libunwind supports similar to GDB.
  In GDB manual they had mentioned about this issue (I sent that link in my previous mail) also I read that after posting it on this mailing list otherwise I wouldn't have posted. 
  libunwind works only with test programs works not with library. I had tried all the examples posted in libwunwind site (didn't get time to tweak the code) and searched on net.
 


GDB way of producing stack trace
---------------------------------------------------

3.1 Prologue Analysis

To produce a backtrace and allow the user to manipulate older frames' variables and arguments, gdb needs to find the base addresses of older frames, and discover where those frames' registers have been saved. Since a frame's “callee-saves” registers get saved by younger frames if and when they're reused, a frame's registers may be scattered unpredictably across younger frames. This means that changing the value of a register-allocated variable in an older frame may actually entail writing to a save slot in some younger frame.

Modern versions of GCC emit Dwarf call frame information (“CFI”), which describes how to find frame base addresses and saved registers. But CFI is not always available, so as a fallback gdb uses a technique called prologue analysis to find frame sizes and saved registers. A prologue analyzer disassembles the function's machine code starting from its entry point, and looks for instructions that allocate frame space, save the stack pointer in a frame pointer register, save registers, and so on. Obviously, this can't be done accurately in general, but it's tractable to do well enough to be very helpful. Prologue analysis predates the GNU toolchain's support for CFI; at one time, prologue analysis was the only mechanism gdb used for stack unwinding at all, when the function calling conventions didn't specify a fixed frame layout.

In the olden days, function prologues were generated by hand-written, target-specific code in GCC, and treated as opaque and untouchable by optimizers. Looking at this code, it was usually straightforward to write a prologue analyzer for gdb that would accurately understand all the prologues GCC would generate. However, over time GCC became more aggressive about instruction scheduling, and began to understand more about the semantics of the prologue instructions themselves; in response, gdb's analyzers became more complex and fragile. Keeping the prologue analyzers working as GCC (and the instruction sets themselves) evolved became a substantial task.

To try to address this problem, the code in prologue-value.h and prologue-value.c provides a general framework for writing prologue analyzers that are simpler and more robust than ad-hoc analyzers. When we analyze a prologue using the prologue-value framework, we're really doing “abstract interpretation” or “pseudo-evaluation”: running the function's code in simulation, but using conservative approximations of the values registers and memory would hold when the code actually runs. For example, if our function starts with the instruction:

Thanks
Sasi

On Wed, Feb 22, 2012 at 9:03 PM, Arun Sharma <address@hidden> wrote:

On Tue, Feb 21, 2012 at 10:56 PM, Sasikanth <address@hidden> wrote:
> The code i sent u and poor man's profiler r similar. But i had tried with
> poor man's profile ... Same results ... no change
>
> libunwind is not working if the code uses frame pointer for someother
> purpose .......

Two debug techniques:

readelf -wf <binary>

and look for pc=... range that matches the value of RIP you're trying
to unwind from. If there is no unwind info, that's the problem.

You can also use:

./configure --enable-debug
UNW_DEBUG_LEVEL=16 test-program

and post the output to the list or compare to a working test case
(ones included in the test directory).

 -Arun