Stack trace and symbols - HP UX

This is a discussion on Stack trace and symbols - HP UX ; 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 ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Stack trace and symbols

  1. 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


  2. Re: Stack trace and symbols

    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.


    > 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?

  3. Re: Stack trace and symbols


    Christof Meerwald wrote:
    > 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...

    > > 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


  4. Re: Stack trace and symbols

    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.


    >> > 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.


    > 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?

  5. Re: Stack trace and symbols

    Christof Meerwald wrote:
    > 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. :-)

    > > 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


  6. Re: Stack trace and symbols

    >From: "Fab"
    : 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).

    >From: Christof Meerwald
    >you will have to open the file on the disk.


    Right, files if handling shared libs.

  7. Re: Stack trace and symbols

    > 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?


    the dladdr() API should do this. its prototype and related data
    structure declarations can be found in /usr/include/dlfcn.h .


  8. Re: Stack trace and symbols

    ranga wrote:
    >: the dladdr() API should do this.


    As mentioned previously by Fab, he already tried shl_getsymbols.
    This has 2 problems, same as dladdr.
    1) Only symbols known to dld appear.
    2) These symbols point to import stubs, if present with older +DA1.1, and
    you would need to decompile them to get to the real code address.

+ Reply to Thread