pc_requires_run_before_use

pc_requires_run_before_use

[Randolph Chung]

Does anybody understand what this comment means or what this code is
supposed to do?

hppa_pc_requires_run_before_use() in hppa-tdep.a says:

  /* Sometimes we may pluck out a minimal symbol that has a negative address.

     An example of this occurs when an a.out is linked against a foo.sl.
     The foo.sl defines a global bar(), and the a.out declares a signature
     for bar().  However, the a.out doesn't directly call bar(), but passes
     its address in another call.

     If you have this scenario and attempt to "break bar" before running,
     gdb will find a minimal symbol for bar() in the a.out.  But that
     symbol's address will be negative.  What this appears to denote is
     an index backwards from the base of the procedure linkage table (PLT)
     into the data linkage table (DLT), the end of which is contiguous
     with the start of the PLT.  This is clearly not a valid address for
     us to set a breakpoint on.

     [...] */

what is the case that this code is trying to catch? i tried to duplicate
the problem described above using this test program:

#include <stdio.h>
#include <string.h>

static int foo(size_t (*func)(const char *), const char *arg)
{
    printf("func = %p\n", (void *)func);
    return func(arg);
}

int main(int argc, char **argv)
{
    return foo(strlen, argv[0]);
}

and putting a breakpoint on "strlen" before starting to run the program.

on hppa-linux and hppa1.1-hp-hpux11.11, we do not trigger the check
above, and breakpoints work fine.

on hppa64-hp-hpux11.11, we are not able to put a proper breakpoint on a
shared lib function before starting the executable:

(gdb) b strlen
Breakpoint 1 at 0x800000010000bc80
(gdb) run
Starting program: /home/tausq/foo
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x800000010000bc80: I/O error.

in either case we are not getting the problem that this hook is trying
to catch...

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: pc_requires_run_before_use

[John David Anglin]

> Does anybody understand what this comment means or what this code is
> supposed to do?
> 
> hppa_pc_requires_run_before_use() in hppa-tdep.a says:

I haven't looked at this but I think this is typical of the plabel
setup for lazy binding.  In GCC under linux, we need to call into
the dynamic linker to force resolution of the function when doing
function pointer comparisons.  This is the infamous __cffc routine.
I think gdb will have similar issues when trying to set a break
in a shared library.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: pc_requires_run_before_use

[Randolph Chung]

> I haven't looked at this but I think this is typical of the plabel
> setup for lazy binding.  In GCC under linux, we need to call into
> the dynamic linker to force resolution of the function when doing
> function pointer comparisons.  This is the infamous __cffc routine.
> I think gdb will have similar issues when trying to set a break
> in a shared library.

no, i don't think that's it:

(gdb) b printf
Function "printf" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n

gdb is pretty smart about this....

we used to have problems stepping into shared lib functions before they
have been resolved by the loader, but this has been fixed some time
back.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: pc_requires_run_before_use

[Randolph Chung]

In reference to a message from John David Anglin, dated Nov 23:
> > Does anybody understand what this comment means or what this code is
> > supposed to do?
> > 
> > hppa_pc_requires_run_before_use() in hppa-tdep.a says:

hrm, i found a testcase for this (gdb.base/so-indr-cl). It's
hpux-specific.

if we create one shared object that exports a function, and then use
that function from the main program via an indirect reference, then we
trip the check. there's a bit more explanation in the testcase:

# This program implicitly loads SOM shared libraries.  We wish to test
# whether a user can set breakpoints in a shlib before running the
# program, where the program doesn't directly call the shlib, but
# indirectly does via passing its address to another function.
#
# ??rehrauer: Currently, this doesn't work, but we do catch the case
# and explicitly disallow it.  The reason it fails appears to be that
#
#  [1] gdb consults only the linker symbol table in this scenario, and
#  [2] For a shlib function that is only indirectly called from the
#      main a.out, there is in the linker symbol table a stub whose
#      address is negative.  Possibly this is to be interpreted as
#      an index into the DLT??

interestingly, this only triggers when calling a function in a
user-defined shared object. in my original test program which calls a
function in libc.sl, the problem doesn't occur. i don't know why yet....
i wish there were a "readelf" equivalent for SOM... :)

using the same testcase on linux, the reference to the shared object
function is not picked up by gdb for the main program before the app is
started, so the problem doesn't exist. i guess this may be a problem
with the SOM reader where it records a symbol for the unresolved
reference to a shlib function....

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: pc_requires_run_before_use

[John David Anglin]

> # ??rehrauer: Currently, this doesn't work, but we do catch the case
> # and explicitly disallow it.  The reason it fails appears to be that
> #
> #  [1] gdb consults only the linker symbol table in this scenario, and
> #  [2] For a shlib function that is only indirectly called from the
> #      main a.out, there is in the linker symbol table a stub whose
> #      address is negative.  Possibly this is to be interpreted as
> #      an index into the DLT??
> 
> interestingly, this only triggers when calling a function in a
> user-defined shared object. in my original test program which calls a
> function in libc.sl, the problem doesn't occur. i don't know why yet....
> i wish there were a "readelf" equivalent for SOM... :)

Have you tried odump?  There is a manpage for it on uly3.

> using the same testcase on linux, the reference to the shared object
> function is not picked up by gdb for the main program before the app is
> started, so the problem doesn't exist. i guess this may be a problem
> with the SOM reader where it records a symbol for the unresolved
> reference to a shlib function....

I haven't looked into the mechanics of this as I did for linux.  There is
info on binding in the ld and dld.sl manpages.  There is a millicode
routine $$sh_func_adrs that performs function pointer canonicalization.
Possibly, understanding the deferred binding mechanism may allow you
to detect unresolved references to shlib functions.

This is obviously a pain for the user who wants to place a break
on such a function.  I usely use static linkage or immediate binding
when I encounter problems such as this.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)