You shouldn't need to translate the stack frame. You do, however, need symbols.

For example, if your 'app.core' is the core file of your application 'app', then start gdb like this:

gdb app --core app.core

where 'app' should be compiled with '-g' compiler option (or even better '-g2' or '-g3').

With that, you should see informative backtrace.


To try to answer questions regarding addresses (hopefully you won't need to use them):

On x86 targets, 0xb... addresses typically mean the frame is in a shared library (possibly libc). If the core is 
complete, 'info sharedlibrary' should give you an idea of libraries loaded. 0x0... are *probably* in your code 
(executable).

Note that current gdb shows load-addresses (in info sharedlibrary output) that do not align with what one can expect, 
but to see where your library is really loaded use "pidin mem" on your target while your application is running (before 
crashing). Typically, the load address of shared libraries will be the same between runs. You only need this if you need
 to decipher stacktrace from addresses only; then you would get your stack address, from load bases of shared objects 
see to which object the address belongs, subtract object's load base (the one you got with 'pidin mem') and then use 
that offset to lookup symbol in the containing file. This is all done for you by gdb providing you have a valid core 
file and executable with symbols.


sabtain khan wrote:
> Hello,
>         I am using GDB to troubleshoot a core dump file. Unfortunately, the core dump file does not have a lot of 
symbols and the stack frames only have the adresses. The adresses are of two different type
> 
> one starting with 0x0 - the symbols of these frame are available
> Others starting with 0xb - they do not have any symbol information available.
> 
> I am presuming that is because the applciation is using shared object library. I can create an object dump of the 
shared object file. and I know how to disassemble the program given correct adresses.
> 
> However, I do not know what is the different between the two type of addresses is. I do not know if I have to 
substract the beginning address from the innermost frame address or what?
> 
> Can someone please tell me how can I translate the stack frame addresses to figure out what line of code is being 
called
> 
> Thanks,
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post13471
> 

Yes 0xb address is shared library code. But you need to know to which library it belongs and what is address at which 
shared library was loaded.
This information should be available from core file. When you do Postmortem debugging in IDE you can open Modules view 
and it should show library name and load address.
To get symbols you need to substruct load address from frame address and it would address of symbol (instruction) in 
your shared library.
If it has symbols gdb should be able to do it for you. You need to add shared library search path in the debugger launch
 config settings (Debug tab->Shared Libraries).
Name of the library in the search path must match exactly name in the Modules view for debugger to load symbols.


sabtain khan wrote:
> Hello,
>         I am using GDB to troubleshoot a core dump file. Unfortunately, the core dump file does not have a lot of 
symbols and the stack frames only have the adresses. The adresses are of two different type
> 
> one starting with 0x0 - the symbols of these frame are available
> Others starting with 0xb - they do not have any symbol information available.
> 
> I am presuming that is because the applciation is using shared object library. I can create an object dump of the 
shared object file. and I know how to disassemble the program given correct adresses.
> 
> However, I do not know what is the different between the two type of addresses is. I do not know if I have to 
substract the beginning address from the innermost frame address or what?
> 
> Can someone please tell me how can I translate the stack frame addresses to figure out what line of code is being 
called
> 
> Thanks,
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post13471
>