From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13757 invoked by alias); 18 Jun 2003 12:11:41 -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 13735 invoked from network); 18 Jun 2003 12:11:40 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 18 Jun 2003 12:11:40 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3p2/8.9.3) with ESMTP id IAA21365; Wed, 18 Jun 2003 08:04:56 -0400 Received: from dash ([192.168.20.31]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id IAA06612; Wed, 18 Jun 2003 08:11:38 -0400 Message-ID: <003301c33594$3e6bccf0$2a00a8c0@dash> From: "Kris Warkentin" To: "Kevin Buettner" , "Michael Snyder" Cc: "Daniel Jacobowitz" , "Gdb@Sources.Redhat.Com" 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> Subject: Re: Why does solib_open do what it does? Date: Wed, 18 Jun 2003 12:11:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SW-Source: 2003-06/txt/msg00372.txt.bz2 > 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. They'll probably whine if I take it out. 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. > 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. > 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