From: Michael Eager <eager@eagercon.com>
To: Daniel Jacobowitz <drow@false.org>, gdb@sourceware.org
Subject: Re: Finding ld.so dynamic loader
Date: Wed, 30 Jan 2008 18:31:00 -0000 [thread overview]
Message-ID: <47A0C27E.2090206@eagercon.com> (raw)
In-Reply-To: <20080130174641.GA24736@caradoc.them.org>
Daniel Jacobowitz wrote:
> On Wed, Jan 30, 2008 at 09:00:35AM -0800, Michael Eager wrote:
>> IMO, if this prefix is not set by the user, the environment
>> symbol or path should be searched, with the host system searched
>> as a final choice. I can create a patch to do this if desired.
>
> It's harder than it sounds to figure out whether we're native
> debugging or remote debugging once you're down in the shared library
> code; I don't think it's worth it. I have no preference whether we
> search the solib-search-path before or after the sysroot, though I am
> a little worried about breaking existing setups...
There's a chain of calls from remote_open() to enable_break()
to solib_open(). It would be possible to set a global flag
(arrgh!) in remote_open() which could be checked in solib_open().
It would also seem reasonable to have a flag set in the gdb-arch
code to say not to search host system directories.
Somewhere along the way the principle of least surprise should
kick in. I only noticed this because my target has a dynamic
loader named "/lib/ld.so.1". If it had been "/lib/ld-linux.so.2"
then gdb would have quietly placed a breakpoint on the target
at whatever location would be correct on the host system.
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
next prev parent reply other threads:[~2008-01-30 18:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-30 16:42 Michael Eager
2008-01-30 16:51 ` Daniel Jacobowitz
2008-01-30 17:00 ` Michael Eager
2008-01-30 17:47 ` Daniel Jacobowitz
2008-01-30 18:31 ` Michael Eager [this message]
2008-01-30 16:53 ` Michael Eager
2008-01-30 18:28 ` Mark Kettenis
2008-01-30 18:45 ` Michael Eager
2008-01-30 19:04 ` Paul Koning
2008-01-30 21:06 ` Michael Eager
2008-01-30 21:30 ` Mark Kettenis
2008-01-31 11:27 ` Michael Snyder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47A0C27E.2090206@eagercon.com \
--to=eager@eagercon.com \
--cc=drow@false.org \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox