Are there any tools to translate offsets as seen on GDB stacktraces to library calls?
If not , how can you identify the call manually?
translate offsets to library calls
- tonyw
- AmigaOS Core Developer
- Posts: 1479
- Joined: Wed Mar 09, 2011 1:36 pm
- Location: Sydney, Australia
Re: translate offsets to library calls
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.
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.
cheers
tony
tony
Re: translate offsets to library calls
I triedtonyw 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.
>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.)
Re: translate offsets to library calls
addr2line will look in the void if you don't give the address in questionI tried
>addr2line -j.text -sfe guis:g4T11
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>
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
- tonyw
- AmigaOS Core Developer
- Posts: 1479
- Joined: Wed Mar 09, 2011 1:36 pm
- Location: Sydney, Australia
Re: translate offsets to library calls
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
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
cheers
tony
tony
Re: translate offsets to library calls
@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
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
- broadblues
- AmigaOS Core Developer
- Posts: 600
- Joined: Sat Jun 18, 2011 2:40 am
- Location: Portsmouth, UK
- Contact:
Re: translate offsets to library calls
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.
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.
Re: translate offsets to library calls
@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 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?
- broadblues
- AmigaOS Core Developer
- Posts: 600
- Joined: Sat Jun 18, 2011 2:40 am
- Location: Portsmouth, UK
- Contact:
Re: translate offsets to library calls
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.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?
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
Re: translate offsets to library calls
@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).
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).
AmigaOne X1000 running AOS 4 beta
AmigaOne XE/G4
Amiga 1200/PPC 603e + BVision PPC
AmigaOne XE/G4
Amiga 1200/PPC 603e + BVision PPC