From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19966 invoked by alias); 18 Jun 2003 01:43:40 -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 19940 invoked from network); 18 Jun 2003 01:43:39 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 18 Jun 2003 01:43:39 -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 VAA07150; Tue, 17 Jun 2003 21:36:58 -0400 Received: from dash ([192.168.20.36]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id VAA04488; Tue, 17 Jun 2003 21:43:37 -0400 Message-ID: <005101c3353c$80077c70$2a00a8c0@dash> From: "Kris Warkentin" To: "Michael Snyder" , "Kevin Buettner" 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> Subject: Re: Why does solib_open do what it does? Date: Wed, 18 Jun 2003 01:43: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/msg00369.txt.bz2 > > Michael, any comments? > > I don't remember. ;-( > I'll just remark that ld puts full paths in for some libs, and not for others. > That's why there are two variables, SOLIB-SEARCH-PATH and > SOLIB-ABSOLUTE-PREFIX. One is the prefix that goes before everything > (even rooted filespecs), and the other is the additional prefix that > goes before an un-rooted filespec. Okay then, here's what I propose. 1) Change the order as Kevin suggested earlier. This give the user plenty of opportunity to tell gdb how to find the solibs before we thrash about desperately in LD_LIBRARY_PATH, etc. 2) Take out the solib_search_path check in the if(found_file <0 && solib_search_path != NULL) parts of the last two desperation plays. I don't think there's any reason for them. I have a feeling that we want to leave the last two searches in place simply because native debugging is the most common and they probably catch a lot of action. Most people doing remote debugging are setting up their solib-absolute-prefix and such properly anyway. Sound reasonable? cheers, Kris