Re: dladdr alternative for static "t" symbols?

[Brendan Miller <catphive at catphive dot net>]

On Tue, Aug 11, 2009 at 7:50 AM, Carlos O'Donell<carlos@systemhalted.org> wrote:
> You will end up duplicating much of the functionality in gdb.
Yes, that is the goal. Except I want to invoke it in process to
generate the backtrace which I'm going to pop into an exception so
that we can get exception stack traces in my logs, and generally make
my code base easier to debug.

The stack walking and name demangling already work fine using glibc
and libstdc++ interfaces. Mostly I just want some way to parse out the
static symbols that dladdr can't find, and as as bonus *maybe* some
way to get the line numbers, although I don't think that's as big of a
deal.

> If you want to recreate this, you have a lot of work ahead of you, and
> I would suggest the following alternative. There was, at one point in
> the past, talk about enhancing gdb such that you could invoke the
> debugger as a library call to perform a backtrace for your program. I
> think that would be cool. It wouldn't be fast but it would be
> *extremely* accurate, and it would get better as gdb got better.

That's a possibility. It looks like there's some kind of libgdb2
project within gdb... I am concerned about speed, and also licensing
issues though. I'm not clear on whether the libgdb2 stuff uses GPL or
LGPL for their interfaces. I can't link with plain GPL since this is
going into shipping software.

Hmm... I guess if I had a library that could parse the ELF binary, I
could pull all the static symbols out and put them into a map, doing
the parsing work upfront when my various binaries launch, then the
symbol lookup could be efficient enough to do when throwing an
exception.

nm can get "t" symbols out of binaries... so as a super lame hack I
could potentially just execute that and pipe the input back in and
parse the output.

With shared libraries the addresses are going to be offset though
right? I'm not sure how to figure out what the offset is at runtime to
compute the runtime address of the static functions.

Does glibc have some kind of interface for finding the runtime offset
of where a library has been loaded into? Also, maybe some kind of hook
that gets called when a new library is loaded?

Thanks,
Brendan