Re: pc_requires_run_before_use

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

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