From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21564 invoked by alias); 3 Dec 2003 21:20:08 -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 21555 invoked from network); 3 Dec 2003 21:20:05 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 3 Dec 2003 21:20:05 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id QAA14860; Wed, 3 Dec 2003 16:32:46 -0500 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id QAA24723; Wed, 3 Dec 2003 16:20:05 -0500 Message-ID: <06c101c3b9e3$5cd789d0$0202040a@catdog> From: "Kris Warkentin" To: "Kevin Buettner" , "Gdb@Sources.Redhat.Com" References: <064801c3b9d6$5de8e5b0$0202040a@catdog> <1031203203529.ZM1946@localhost.localdomain> Subject: Re: interesting solib-absolute-prefix problem Date: Wed, 03 Dec 2003 21:20: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.1165 X-SW-Source: 2003-12/txt/msg00065.txt.bz2 > > To make a long story short, I put an 'open() of last resort' in solib_open > > right at the end where if all else fails, it tries to open the exact path it > > was given. It would seem to me that this is probably not too dangerous but > > someone might be able to comment on this better than I. > > I don't really like this patch. If someone sets solib-absolute-prefix > incorrectly - a quite common occurrence, I've found - we don't want to > inadverently open the host's /lib/libc.so (or the like). In this case, > it's preferable for gdb to print an error message. I'm not super fond of it either. I was actually tempted to put a warning in that bit of code to tell the user that it found the library there and that it might not be what they wanted. Note that in our case, we actually initialize solib-absolute-prefix within the code based on our environment. > It would, perhaps, be less misleading if GDB were to list the paths > that it tried (and failed) to open. Perhaps. The net result is still that it had the exact path the the lib and still couldn't find it. > It's still not clear to me why you need solib-absolute-prefix set when > doing native debugging. (You explained it above, but I don't understand > your environment well enough to comprehend the explanation.) It's a bit screwy....you'll probably just have to trust me on it. If it makes you feel better, I can give an example of the problem when doing remote debugging. Say I'm in my homedir on a cygwin machine. I export a CIFS dir /home/kewarken/foo where I build my app. My remote machines homedir has foo mounted. So /home/kewarken/foo/libmylib.so is exactly the same path on the local and the remote. I've got solib-absolute-prefix set to find my system libs but I would hope that gdb would find libmylib.so properly because its location is the same on the host and target. As it stands, it doesn't. Would printing something like: "Warning: opening without using solib-absolute-prefix. You may need to set solib-search-path." make it a little better? I could also test for solib_absolute_prefix like so: + if (solib_absolute_prefix != NULL && found_file < 0 && (found_file = open (orig, O_RDONLY, 0)) > -1) + temp_pathname = orig; It seems to me that if we accidentally opened up the wrong libc.so, for example, we would have some fairly catastrophic failure anyway. You'd have to have a pretty seriously misconfigured system for that to happen, especially since this last ditch check happens after all other search paths are used. cheers, Kris