Hyperion Entertainment Message Boards

Are there any tools to translate offsets as seen on GDB stacktraces to library calls?
If not , how can you identify the call manually?

Yes, there is the "addr2line" command.

Compile your code with the "-gstabs" option in the compile line. Don't strip the binary.

When you have the stack trace, it says something like 0xAAAAAAAA (offset 0xBBBBBBBB).
Type "addr2line -j.text -sfe <binary name>" and it will print out the source file name, function name and the source line number.

tonyw wrote: When you have the stack trace, it says something like 0xAAAAAAAA (offset 0xBBBBBBBB).
Type "addr2line -j.text -sfe <binary name>" and it will print out the source file name, function name and the source line number.

I tried
>addr2line -j.text -sfe guis:g4T11


but i don't get any output.

I did find the --help opton and tried aboot anything that shows up in the stactrace, but as the -j."section identification" option without succes

Stack trace:

native kernel module newlib.library.kmod+0x00002054
native kernel module newlib.library.kmod+0x00002ca0
native kernel module newlib.library.kmod+0x00002e64
g4T11:_start()+0x170 (section 1 @ 0x170)
native kernel module dos.library.kmod+0x00020a14
native kernel module kernel+0x0003af4c
native kernel module kernel+0x0003afcc


What should i use as -j.text ??


If it works addr2line gives me more than i asked for.
In fact having just the library function called corresponding to a given offset is what i looked for initially.
(or the offset corresponding to a library call would be OK too.)

I tried
>addr2line -j.text -sfe guis:g4T11

addr2line will look in the void if you don't give the address in question

Unfortunately your stack trace does not provide one besides the entry point (_start) of your program which doesn't help a lot
(If i'm talking BS please some dev shut me off )

If you ever get an address you should try
addr2line -j.text -sfe guis:g4T11 <your address, like 0xBB0B8A>

Sorry, I forgot the address part.

I use an alias called "whereis". For all my development work, the makefile always saves the full (unstripped) version of the binary as a local file called "currimage". The alias is defined thus:

Alias whereis addr2line -j.text -sfe currimage []

The ".text" is a section within the ELF file and you don't change it.
The "currimage" is the name of your unstripped binary. Plug your own filename in there.
The "[]" is where the offset goes. So, if I have a stack trace line that says (for example):
#8: in module Kickstart/env-handler.kmod+0x00000610 (0x0158B0B4)

- then I would type "whereis 610" and the alias searches the file "currimage". The answer would appear:

>whereis 610 <<< NB don't need '0x'
EnvHandler <<< function name
dispatch.c:246 <<< source file and line

@tonyw

Thanks. At least i can get some response now from addr2line, though not very exciting.


12.Amiga OS 4:S> addr2line -j.text -sfe guis:g4T11 170
_start
??:0



I get the stacktrace in previous mail when i start the program.

Can the lines other lines in the stacktrace be of any help

To make the ouput more inetresting that 0:?? you must compile all your code with -gstabs.

Any lne in the stack trace that corresponds to your program (rather than a library used by it) might be of interest, but generally the last line of *your* code is where you should start to look.

Edit: Looking more closlely at you previous post you crash before you program code is ever called, or seem to. You could try removing any optimisation ie compile without any -O options sometimes that gives abetter stack trace.

@broadblues

I was using -gstabs and not optimizing.

In other sources i am now able to use addr2line to satisfaction now.

I still wonder what the adresses GDB provides eg
"native kernel module dos.library.kmod+0x00020a14 " mean. I guess it is the offset identifying a called dos function, so is there no mean to identify this lookng in the docs? After all the compiler has to do this too?

I guess it is the offset identifying a called dos function, so is there no mean to identify this lookng in the docs? After all the compiler has to do this too?

It does mean it's a crash nside a dos.library function, but only a developer with access to a debug version can tell where.

The compiler only cares about the offsets with the inetrface structure, and the odds of that being the location of the crash or very small (if not 0)

With crashes inside a system library you should work back up the stack trace till you find the last line of you own code, then you can usually see what functuion you called that crashed. Sometimes though it may be a C function (newlib or clib2) that calls the dos function.

Debugging is a puzzle / detective game

@Broadblues

I have an example where this is not possible, I think it's due to the fact that I'm launching several "sub" processes using CreateNewProc() which seems to disturb stack traces... I'm not totally sure because this is also a special case where my program is called by the system (an handler).