1. If the stack includes "main", then that is all there is. ;-)
2. You may get better answers from a newer wdb from
http://www.hp.com/go/wdb .
3. You may get better answers from a newer libcl.2 such as in patch PHSS_27469 for 11.00. The stack unwind routines are in libcl.2, (but wdb might have its own.)
4. If the program has damaged the stack, you may be able to get more information by dumping the stack contents yourself.
Even when a stack is too damaged for wdb to unwind it, there are
probably several real return addresses in the stack. You can dump the
contents of the stack yourself and try to pick out the addresses that
are return pointers. The "/a" format will print an address as an offset
from a symbol if it's value is close to some symbol.
You could use wdb and a command like
set print array on
print /a (*($sp-200))@50
or
set print array on
set print elements 500
print /a (*($sp-2000))@500
Then look for an interesting pattern of function addresses. The last
data printed would be closest to the final routine that core dumped. There
will probably be a few values that look like return pointers but are not
really used as return pointers. That leaves room for imagination and
detective work identifying the plausible situations that match the
evidence. Try using the mechanism when you can see the call stack to
get an idea what to expect.
Real return pointers have low bits of 0x3, (indicating a low privilege
level). You can use the "disassemble" command to examine around likely
return addresses to see if they follow a calling instruction such as bl,
ble, or bve. If the code did not make a call it is not a true return
address.
---------------------------------------------------------------------------
