This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA/hpux] SEGV when running program using dlopen
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Randolph Chung <randolph at tausq dot org>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Wed, 15 Dec 2004 20:57:38 +0400
- Subject: Re: [RFA/hpux] SEGV when running program using dlopen
- References: <20041215073206.GM964@adacore.com> <20041215163628.GY29171@tausq.org>
> since we are already doing this in an ALL_OBJFILES loop, how come we
> don't find the right symbol?
The answer is in the body of lookup_minimal_symbol_solib_trampoline().
It iterates over all msymbols of the objfile, and returns the first
one whose name matches *and* whose ``MSYMBOL_TYPE (msymbol) ==
mst_solib_trampoline''. See minsyms.c, around line 353.
Since in our case, the symbol we're looking for is not inside
a shared library, the lookup always fails.
I was also wondering whether the current code might be working
by pure luck in the other case. Assuming that the objfile contains
two symbols (one stub, one function) in the shared library, what
guaranty do we have that the lookup will find the one we're looking
for?
> i also notice that the problem only occurs when you link in end.o;
> what does that do?
AFAIK, it provides some help in debugging by exporting some specified
symbols. The only use I know of if with shared libraries...
--
Joel