Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@redhat.com>
To: "Kris Warkentin" <kewarken@qnx.com>
Cc: "Michael Snyder" <msnyder@redhat.com>,
	"Daniel Jacobowitz" <drow@mvista.com>,
	"Gdb@Sources.Redhat.Com" <gdb@sources.redhat.com>,
	"Kevin Buettner" <kevinb@redhat.com>
Subject: Re: Why does solib_open do what it does?
Date: Thu, 19 Jun 2003 23:33:00 -0000	[thread overview]
Message-ID: <1030619231615.ZM4725@localhost.localdomain> (raw)
In-Reply-To: "Kris Warkentin" <kewarken@qnx.com> "Re: Why does solib_open do what it does?" (Jun 19,  8:24am)

On Jun 19,  8:24am, Kris Warkentin wrote:

> > > In Linux it's the case for all searched-for objects, as far as I know -
> > > anything found via search paths, LD_LIBRARY_PATH, DT_RUNPATH, DT_RPATH,
> > > etc. will either be an absolute path or else contain slashes and be
> > > relative to the current directory.  If it's not true for dlopen'd
> > > objects, well, there's no way to know where the app had chdir'd to when
> > > it loaded them.
> > >
> > > Do you know offhand when it's not true for GNU/Linux?
> >
> > No, I just recall that, several years ago when I worked on this code,
> > it was not always true.
> 
> Okay gentlemen, all kidding aside, what do we do?  At the bare minimum I
> believe the test
> 
>   /* If not found, next search the inferior's $PATH environment variable. */
>   if (found_file < 0 && solib_search_path != NULL)
> 
> should be just:
> 
> if (found_file < 0).
> 
> We can always make a decision about removing the PATH and LD_LIBRARY_PATH
> checks later.

Okay, I've come to a decision.

It's still not clear to me if the PATH and LD_LIBRARY_PATH searches
are needed for natives.  Either they're not needed or nobody's noticed
that some previously available functionality (prior to Nov 21, 2000)
is now missing.  I do know, however, that we definitely don't want to
do these searches for (most) remote targets.  In light of Michael's
remarks, I'm now inclined to be more cautious about removing these
searches than I was originally.

Further, if you're debugging a remote target, you'd better have
solib-absolute-prefix set, or things will almost certainly go wrong. 
To the best of my knowledge, when you're debugging a native target,
you never set solib-absolute-prefix, so the fact that this is set or
not gives us a cheap, but effective way to determine whether the
intent is to run on a native target or not.

Actually, it's better than that.  Something that I occassionally do is
to run against a "native" rda or gdb server where I don't set
solib-absolute-prefix.  Doing things in this fashion will make search
algorithm for this kind of "remote" (which is really a native
disguised as a remote) target identical to running a native and that
is precisely what's desired.

So...  I'd like to see the checks preceding the PATH and LD_LIBRARY_PATH
searches changed from:

  if (found_file < 0 && solib_search_path != NULL)

to:

  if (found_file < 0 && solib_absolute_prefix == NULL)

Kris, I believe you volunteered to make the necessary changes.  Would
you like to do the honors?  BTW, your proposed comment changes look
good too.  Consider these changes preapproved, but do make sure you
post the patch that you end up committing.

Thanks,

Kevin


  reply	other threads:[~2003-06-19 23:33 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-17 19:01 Kris Warkentin
2003-06-17 19:13 ` Daniel Jacobowitz
2003-06-17 19:14   ` Kris Warkentin
2003-06-17 19:37     ` Elena Zannoni
2003-06-17 19:47       ` Kris Warkentin
2003-06-17 20:01     ` Kevin Buettner
2003-06-17 20:15       ` Kris Warkentin
2003-06-17 20:24         ` Kevin Buettner
2003-06-18  0:14           ` Michael Snyder
2003-06-18  1:43             ` Kris Warkentin
2003-06-18  5:33               ` Kevin Buettner
2003-06-18 12:11                 ` Kris Warkentin
2003-06-18 15:07                   ` Kris Warkentin
2003-06-18 18:52                     ` Michael Snyder
2003-06-18 19:09                       ` Kris Warkentin
2003-06-18 19:20                         ` Andrew Cagney
2003-06-18 20:10                         ` Michael Snyder
2003-06-18 20:17                           ` Kris Warkentin
2003-06-18 19:14                       ` Daniel Jacobowitz
2003-06-18 18:45                   ` Michael Snyder
2003-06-18 18:41                 ` Michael Snyder
2003-06-18 19:16                   ` Daniel Jacobowitz
2003-06-18 20:11                     ` Michael Snyder
2003-06-18 20:19                       ` Kris Warkentin
2003-06-18 20:27                       ` Daniel Jacobowitz
2003-06-18 20:51                         ` Michael Snyder
2003-06-19 12:24                           ` Kris Warkentin
2003-06-19 23:33                             ` Kevin Buettner [this message]
2003-06-20  0:02                               ` Kevin Buettner
2003-06-20 12:28                                 ` Kris Warkentin
2003-06-20 12:43                                   ` Kevin Buettner

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=1030619231615.ZM4725@localhost.localdomain \
    --to=kevinb@redhat.com \
    --cc=drow@mvista.com \
    --cc=gdb@sources.redhat.com \
    --cc=kewarken@qnx.com \
    --cc=msnyder@redhat.com \
    /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