|
|
|
|
|
|
| Author |
Message |
Fab
*nix forums beginner
Joined: 07 Jul 2006
Posts: 3
|
 Posted: Fri Jul 07, 2006 10:13 am Post subject:
Stack trace and symbols
|
|
|
Hello everyone,
with the aim of better understanding the origin of an insidious bug in
the code I'm working on, I implemented a "callstack" function which
returns the addresses of the chain of callers which eventually call the
function from which callstack() is called from.
To write that function I used the information found in the 32-bit
PA-RISC Run-time Architecture Document, a copy of which can be found at
http://ftp.parisc-linux.org/docs/arch/rad_11_0_32.pdf
Now, that function works just fine, but all it gives me are
addresses... What I want to do is translate those addresses in symbol
names, much like U_STACK_TRACE() from libcl.sl does. The question is:
how to do it? The dld.sl API doesn't help me here, because although I
can identify the shared library (or the main executable) where the
function corresponding to a given address resides in (by means of
tstart and tend fields of the shl_descriptor structure), I can't narrow
the search down to a specific symbol as the shl_get_symbols() function
returns the addresses of the function stubs rather than the function
themselves.
Is there any API I can use to find the real locations of the symbols in
the libraries, or should I resort to manual parsing of the libraries
symbol tables? In the latter case, where can I find information on the
SOM executable format?
Just in case it may be of help, this is what uname -rsvm gives:
$ uname -rsvm
HP-UX B.11.11 U 9000/800
Thanks in advance,
Fab |
|
| Back to top |
|
 |
Christof Meerwald
*nix forums beginner
Joined: 10 Jul 2006
Posts: 3
|
| Posted: Mon Jul 10, 2006 8:18 am Post subject:
Re: Stack trace and symbols
|
|
|
On 7 Jul 2006 03:13:18 -0700, Fab wrote:
[...]
| Quote: | To write that function I used the information found in the 32-bit
PA-RISC Run-time Architecture Document, a copy of which can be found at
http://ftp.parisc-linux.org/docs/arch/rad_11_0_32.pdf
[...]
tstart and tend fields of the shl_descriptor structure), I can't narrow
the search down to a specific symbol as the shl_get_symbols() function
returns the addresses of the function stubs rather than the function
themselves.
|
You get a procedure label, see 2.5.6 Indirect Procedure Calls in the
Run-time Architecture Document.
| Quote: | symbol tables? In the latter case, where can I find information on the
SOM executable format?
|
See chapters 3 - 5 in the Run-time Architecture Document.
Christof
--
http://cmeerw.org sip:cmeerw at cmeerw.org
mailto:cmeerw at web.de xmpp:cmeerw at cmeerw.org
....and what have you contributed to the Net? |
|
| Back to top |
|
|
Fab
*nix forums beginner
Joined: 07 Jul 2006
Posts: 3
|
| Posted: Wed Jul 12, 2006 2:09 pm Post subject:
Re: Stack trace and symbols
|
|
|
Christof Meerwald wrote:
| Quote: | On 7 Jul 2006 03:13:18 -0700, Fab wrote:
[...]
To write that function I used the information found in the 32-bit
PA-RISC Run-time Architecture Document, a copy of which can be found at
http://ftp.parisc-linux.org/docs/arch/rad_11_0_32.pdf
[...]
tstart and tend fields of the shl_descriptor structure), I can't narrow
the search down to a specific symbol as the shl_get_symbols() function
returns the addresses of the function stubs rather than the function
themselves.
You get a procedure label, see 2.5.6 Indirect Procedure Calls in the
Run-time Architecture Document.
|
Thanks for the tip! I've read those chapters and came up with some code
that successfully retrieves the real address of the symbols (I'm just
not sure whether, apart from clearing bits 0-1, should I also clear
bits 30-31?).
However, I then realized that this way of proceding isn't the most
reliable one, as not all symbols are accessible via shl_getsymbols, but
only the exported ones (as a side note, I was a bit puzzled when I
found that some global symbols from the main executable weren't
accessible by shl_getsymbols, why's that?).
So I think I need to parse the executable files themselves...
| Quote: | symbol tables? In the latter case, where can I find information on the
SOM executable format?
See chapters 3 - 5 in the Run-time Architecture Document.
|
Indeed, had missed that, thanks. Looks like it's not going to be
easy... Oh well. :-)
Just one more question I couldn't find an answer to by myself: do I
need to open the files on disk, or is the information I need already
loaded somewhere? I assume the symbol table doesn't get loaded, right?
Oh... and another question: probably the answer is written somewhere in
the documentation - and I'll go looking for it - but just in case it's
not, but are all the subspaces loaded (or mmap'ed) at the same relative
distance that they have in the executable file? This is important in
order to correctly calculate the symbol value without having to do lots
of relocations: since I'm only interested in code or code-like symbols,
I should be able to just add desc->tstart (returned by shl_get()) to
the symbol value, right?
Fab |
|
| Back to top |
|
|
Christof Meerwald
*nix forums beginner
Joined: 10 Jul 2006
Posts: 3
|
| Posted: Fri Jul 14, 2006 8:50 am Post subject:
Re: Stack trace and symbols
|
|
|
On 12 Jul 2006 07:09:31 -0700, Fab wrote:
| Quote: | However, I then realized that this way of proceding isn't the most
reliable one, as not all symbols are accessible via shl_getsymbols, but
only the exported ones (as a side note, I was a bit puzzled when I
found that some global symbols from the main executable weren't
accessible by shl_getsymbols, why's that?).
|
see man ld -E:
This option is accepted but ignored by the 64-bit ld. Mark all symbols
defined by a program for export to shared libraries. By default, ld marks
only those symbols that are actually referenced by a shared library seen
at link time.
| Quote: | symbol tables? In the latter case, where can I find information on the
SOM executable format?
See chapters 3 - 5 in the Run-time Architecture Document.
Indeed, had missed that, thanks. Looks like it's not going to be
easy... Oh well. 
|
It's actually quite easy to parse the SOM symbol table.
| Quote: | Just one more question I couldn't find an answer to by myself: do I
need to open the files on disk, or is the information I need already
loaded somewhere? I assume the symbol table doesn't get loaded, right?
|
AFAIK, you will have to open the file on the disk.
Christof
--
http://cmeerw.org sip:cmeerw at cmeerw.org
mailto:cmeerw at web.de xmpp:cmeerw at cmeerw.org
....and what have you contributed to the Net? |
|
| Back to top |
|
|
Fab
*nix forums beginner
Joined: 07 Jul 2006
Posts: 3
|
| Posted: Sat Jul 15, 2006 7:42 am Post subject:
Re: Stack trace and symbols
|
|
|
Christof Meerwald wrote:
| Quote: | On 12 Jul 2006 07:09:31 -0700, Fab wrote:
However, I then realized that this way of proceding isn't the most
reliable one, as not all symbols are accessible via shl_getsymbols, but
only the exported ones (as a side note, I was a bit puzzled when I
found that some global symbols from the main executable weren't
accessible by shl_getsymbols, why's that?).
see man ld -E:
This option is accepted but ignored by the 64-bit ld. Mark all symbols
defined by a program for export to shared libraries. By default, ld marks
only those symbols that are actually referenced by a shared library seen
at link time.
|
Thanks! That might turn out to be useful... one day. :-)
| Quote: | Indeed, had missed that, thanks. Looks like it's not going to be
easy... Oh well. :-)
It's actually quite easy to parse the SOM symbol table.
|
Yep, found out that myself. It turned out to be just a few lines of
code, and I didn't have to do any sanity checks since the files were
already checked by the dynamic loader itself when it first opened them.
However, I found out the "hard way" that some information in the
runtime architecture documentation weren't true. For instance, let's
take a symbol of ST_ENTRY type and SS_UNIVERSAL scope: the
documentation says this symbol should have the index of the subspace in
which it resides, in its symbol_info field, but this is not true
because that field, in that case, contains the actual virtual address
of the symbol (as assumed at time of static linking) with the low order
2 bits cleared out as well.
Fab |
|
| Back to top |
|
|
Dennis Handly
*nix forums beginner
Joined: 28 Jun 2005
Posts: 38
|
| Posted: Sat Jul 15, 2006 9:05 am Post subject:
Re: Stack trace and symbols
|
|
|
| Quote: | From: "Fab" <aristofanee@gmail.com
: I've read those chapters and came up with some code |
: that successfully retrieves the real address of the symbols (I'm just
: not sure whether, apart from clearing bits 0-1, should I also clear
: bits 30-31?).
You don't clear the high bits but only the low order 2. But you have to
subtract a bias, see below.
: only the exported ones (I was a bit puzzled when I
: found that some global symbols from the main executable weren't
: accessible by shl_getsymbols, why's that?).
There are two symbol tables. The SOM symbol table and the dld symbol table.
dld only needs to deal with exported symbols so the tables loaded into
memory can be smaller.
You can use /usr/ccs/bin/odump -sym -slexport -slimport to see the two.
U_STACK_TRACE uses the SOM symbol table.
Note the addresses in the two symbol tables can be different for PA1.1.
The dld symbol table points to an export stub.
: So I think I need to parse the executable files themselves...
Yes.
: do I need to open the files on disk, or is the information I need already
: loaded somewhere? I assume the symbol table doesn't get loaded, right?
The SOM symbol tables are not in a loadable space. (Not in a space at all.)
The dld symbol tables are.
So you are going to have to use shl_get to get the beginning and ending
of each load module and their names.
: but are all the subspaces loaded (or mmap'ed) at the same relative
: distance that they have in the executable file?
Only spaces are mapped, not subspaces. And yes, the same offset for all
text and a different one for data.
: This is important in
: order to correctly calculate the symbol value without having to do lots
: of relocations: since I'm only interested in code or code-like symbols,
: I should be able to just add desc->tstart (returned by shl_get()) to
: the symbol value, right?
: Fab
Almost, there is a bias. I think you have to take the symbol - 0x1000,
then add tstart.
For data symbols is is symbol - 0x40001000 and dstart.
(Note these values can be changed when linking with -R and -D, from these
above defaults. You can look at the HP-UX AUX header to get the real
biases:
$ odump -aux /usr/bin/ksh
Auxiliary Header Record (HP-UX) for /usr/bin/ksh:
exec_tsize = 0x00022c0c exec_tmem = 0x00001000 <<
exec_tfile = 0x00001000 exec_dsize = 0x00003000
exec_dmem = 0x40001000 << exec_dfile = 0x00024000
exec_bsize = 0x00001470 exec_entry = 0x00003f98
)
You'll be happy to know on IPF, there will be an API to get the symbol
names. See unwind(5).
| Quote: | From: Christof Meerwald <NOSPAM-seeMySig+ufa5+@usenet.cmeerw.org
you will have to open the file on the disk.
|
Right, files if handling shared libs. |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Mon Dec 01, 2008 11:47 pm | All times are GMT
|
|
Secured Loans | Watch Gossip Girl Online | Credit Cards | Internet Advertising | Arizona Flags
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
HP-UX
