From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1394 invoked by alias); 18 Jun 2003 18:45:23 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 1331 invoked from network); 18 Jun 2003 18:45:21 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 18 Jun 2003 18:45:21 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h5IIjKH21064 for ; Wed, 18 Jun 2003 14:45:21 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h5IIjES26095; Wed, 18 Jun 2003 14:45:14 -0400 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h5IIjDK13917; Wed, 18 Jun 2003 11:45:13 -0700 Message-ID: <3EF0B339.7090804@redhat.com> Date: Wed, 18 Jun 2003 18:45:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Warkentin CC: Kevin Buettner , Daniel Jacobowitz , "Gdb@Sources.Redhat.Com" Subject: Re: Why does solib_open do what it does? References: <09c201c33502$da555ce0$0202040a@catdog> <20030617191129.GA15099@nevyn.them.org> <09e801c33504$bd88b420$0202040a@catdog> <1030617200144.ZM31327@localhost.localdomain> <0ab001c3350d$359af2e0$0202040a@catdog> <1030617202406.ZM31423@localhost.localdomain> <3EEFAEDB.4090509@redhat.com> <005101c3353c$80077c70$2a00a8c0@dash> <1030618051511.ZM11645@localhost.localdomain> <003301c33594$3e6bccf0$2a00a8c0@dash> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00390.txt.bz2 Kris Warkentin wrote: >>Given the fact that these tests are here, I don't think that the $PATH >>and $LD_LIBRARY_PATH checks are ever actually used for native >>debugging. >> >>After all, who bothers to set solib_search_path when doing native >>debugging? And if you do set solib_search_path, doesn't it seem >>strange that these additional checks suddenly become enabled? > > > Hmm...good point. It's probably completely unexercised code. > > >>So, at this point we have two choices: a) Do away with the $PATH and >>$LD_LIBRARY_PATH code altogether, or b) Do as you suggest and remove >>the ``solib_search_path != NULL'' check. >> >>If we can actually convince ourselves that leaving in the $PATH and >>$LD_LIBRARY_PATH checks serve a useful purpose, option b is the way to >>go. At the moment, however, I'm strongly leaning towards option a. > > > Well, we had some customers complain that LD_LIBRARY_PATH stopped working > for them when they stopped setting solib-search-path. They were using it > for remote debugging (somewhat questionable I know) because they have a > central build server that stores most of their libs and then developers > systems have a mount. The administrators set LD_LIBRARY_PATH specifically > for gdb to find these libs when debugging remote targets. Well, that's obviously a kludge, not what they should be doing. We once discussed looking for an environment variable, eg. GDB_SOLIB_SEARCH_PATH, but somebody was against it (maybe Ian Lance Taylor?). Should we revive that idea? > They'll probably whine if I take it out. Too bad -- they're doing something wrong. > Really though, the only places I > can see this being useful is cases like this and when you've got a > misbehaving linker which doesn't fill in the full path. I don't think that is a sign of a misbehaving linker. Some libraries don't have the full path -- that's why there are two gdb variables rather than just one. >>In fact, for remote debugging, leaving these checks in is rather >>dangerous. If, for some reason, the shared lib is not found via >>either solib-absolute-prefix or solib-search-path, we don't want >>to search paths on the host file system which refer to the hosts >>libraries. If the file is found via one of these paths, it is >>almost certainly wrong, and I've seen cases where this can cause >>wildly unpredictable behavior. (E.g, segfaults on the target, or >>breakpoints being hit at strange places.) > > > This was my major problem with checking LD_LIBRARY_PATH. For cross-debugging, yes. I think it would always be wrong. >>I think I could be convinced to leave these checks in if we >>were to replace that ``solib_search_path != NULL'' conjunct with >>``solib_absolute_prefix == NULL'' instead. That is, if you set >>solib_absolute_prefix, then $PATH and $LD_LIBRARY_PATH will never >>be considered. (I guess there were actually three choices. We'll >>call this one option c.) > > > Well, that wouldn't help my customers since we do set solib-absolute-prefix. > On the other hand, there IS solib-search-path and .gdbinit files so I don't > really have a problem with telling them that the LD_L... checking has gone > away. I'll leave the decision to you. I'm just going to remove the > solib_search_path != NULL checks from our shipping version and mark the > behaviour as deprecated if necessary. > > cheers, > > Kris > >