This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cross solib support; continued


Daniel Jacobowitz wrote:
> 
> On Thu, Nov 08, 2001 at 04:24:16PM +0100, Orjan Friberg wrote:
> >
> > That is, I would like a solib that is now searched for in
> > solib-absolute-prefix to be searched for in solib-search-path instead.
> > Would it make sense to add such a command, like solib-ignore-path?  (I'd
> > be happy to make it happen.)  In effect, it would make all solibs to be
> > searched for in solib-search-path by file name only, and
> > solib-absolute-path would have no effect.
> 
> Is this really necessary?  I just put unstripped libraries in a
> directory named lib and set the absolute prefix appropriately.

No, not necessary.  Just convenient for non-gdb hackers ;) .  Basically
I want to supply the users with a nice .gdbinit, so they don't have to
go through any manual steps like making symlinks or coyping solibs.

> Other than that, we should fall back to solib-search-path and the
> basename if solib-absolute-path fails for us, IMO.  Would that work for
> you?  Set the absolute-path to /dev/null or so and then add the
> fallback code.

Yeah, sure.  That sounds much better than my idea.

> > 2. With a work-around for the directory problem above, when I start the
> > program under the gdbserver I get hold of it in _start in ld.so.1, but
> > the symbols for ld.so.1 aren't loaded.  More specifically, I can't "list
> > _start" and backtrace gives me "#0  0x1aaadc34 in ?? ()".  I assume this
> > is because gdb hasn't had a chance to put a breakpoint in ld.so.1 that
> > would make it know about the loading of it.  Chicken-egg problem, but
> > not really a problem; few developers will ever have to debug glibc's
> > startup routines.  I just wanted to check I understand the limitations
> > correctly.  (The stuff in ld.so.1 is loaded by the time I get to main,
> > so that part works.)
> 
> Wait... something doesn't sound quite right.  First of all, _start is a
> symbol in the executable, not in ld.so.1.  Can you look at _dl_start?

Well, _start is a symbol in the executable, but it's a symbol in ld.so.1
also.  It's the first in the .text section:

00001c34 t _start
00001c40 t _dl_start_user
00001c8a t _dl_start
0000205e t _dl_start_final

No, I can't look at _dl_start either at that point, but you answered
that question yourself below.

> The symbols must be loaded (via the .interp and the absolute path) or
> we could not set the breakpoint.
> 
> ... wait, no, that just means we need to find the linker so that we can
> open it and read minsyms.  You're right, no symbols yet.  You can
> probably add them with add-symbol-file, though.  Then you can step to
> debug the startup code, and may be able to set breakpoints.  GDB does
> tend to get a little confused here, though.

Yeah, _start in ld.so.1 doesn't have any debug info, and after I've used
add-symbol-file gdb does get confused and shows me a line of source
belonging to _dl_start, like this:

#0  0x1aaadc34 in _start () at rtld.c:195
195     #ifndef ELF_MACHINE_START_ADDRESS

After some stepi's when I've reached some sane code in _dl_start
everything seems fine and dandy debug-info-wise.

-- 
Orjan Friberg
Axis Communications AB


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]