dlsym() annoyance

[Zack Weinberg]

On Tue, 1 Sep 1998 18:23:19 -0400, Roland McGrath wrote:
>> If I call dlsym(NULL, "sym") and sym is a function in libc that's referred
>> to directly in the program, dlsym returns an address in the PLT, same as
>> writing ptr = sym.  If sym is not referred to directly, I get the actual
>> address inside the shared library. Is there any way to force dlsym to give
>> me the real address in all cases?  (This is for testing purposes, so I don't
>> mind calling internal entry points.)
>
>Nope, there ain't.  If the program itself used "sym", then it was linked
>with a constant address for "sym" (in its PLT), and this is what "&sym"
>means in that program.  If dlsym didn't return the same thing, then
>"&sym" in the program would not be the same as "&sym" as indicated by dlsym.
>
>This is enforced in elf/dl-lookup.c, where it calls elf_machine_lookup_noplt_p
>.
>
>> Also, is there any way to get the text size of an arbitrary function from
>> within the program?
>
>Nope.  The only place that info lives is in the symbol table (st_size), and
>if there is no symbol for a function then the info is lost entirely (at
>link time).  For shared libraries and such, the dynamic symbol table is
>there, but there is no easy way to get at it, except by looking at the
>l_info fields yourself.
>
>
>What is the root reason you want to do these things?

Testing backtrace().  backtracesyms() is useless, so it's necessary to
examine the pointer-list returned by backtrace() directly.  Each of these is
valid iff it is  within the text space of the function expected to be at
that level of the stack trace.  You know which function it is because you
set up the test case.

For functions defined within the program I know the true start address, and
I can get the ending address by assuming that gcc generates the functions in
the order they appear in the file.  If I want to test call chains that go
through libc, I have no way of knowing what comes immediately after any
given function.  The PLT is nowhere near the libc text segment, so it tells
me nothing useful about the validity of a given pointer.

(Incidentally, backtracesyms() is useless because it can only determine
symbol names for exported symbols in shared libraries.  You can't make up
the difference with addr2line because it doesn't know about libraries or
dynamically loaded objects.)

zw