From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27800 invoked by alias); 1 Apr 2004 14:59:26 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 27778 invoked from network); 1 Apr 2004 14:59:23 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 1 Apr 2004 14:59:23 -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 KAA03940; Thu, 1 Apr 2004 10:17:04 -0500 Received: from qnx.com ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with ESMTP id JAA21892; Thu, 1 Apr 2004 09:59:18 -0500 Message-ID: <406C2EA6.2010501@qnx.com> Date: Thu, 01 Apr 2004 14:59:00 -0000 From: Kris Warkentin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: Daniel Jacobowitz CC: "Gdb-Patches@Sources.Redhat.Com" Subject: Re: [patch] Bring QNX Neutrino support forward. References: <4060A9C0.1090906@qnx.com> <20040331222120.GB6811@nevyn.them.org> In-Reply-To: <20040331222120.GB6811@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-04/txt/msg00018.txt.bz2 I've been looking at the *nto-tdep files and it looks like I've got some refactoring to do in order to be current. Particularily the supply_regset stuff and the whole core_fns deprecation thing. Looks icky and I'm not really sure of the best way to do it. I've got 4 other targets besides i386 so I'm looking for the most efficient way. I'm thinking that I might be able to take advantage of more of the generic stuff in i386-tdep.c, at least for that target. Daniel Jacobowitz wrote: >Leading tabs in the ChangeLog entry, please :) Post what you would >check in. > > Lost in translation. They're there in real life. ;-) >>- return openp (buf, 1, solib, o_flags, 0, temp_pathname); >>+ /* Don't assume basename() isn't destructive. */ >>+ base = strrchr (solib, '/'); >>+ if (!base) >>+ base = solib; >>+ else >>+ base++; /* Skip over '/'. */ >> >> > >There's an lbasename in libiberty, for this reason. You should use >that instead. > > > Cool. I did not know that. >>+ ret = openp (buf, 1, base, o_flags, 0, temp_pathname); >>+ if (ret < 0 && base != solib) >>+ { >>+ sprintf (arch_path, "/%s", solib); >>+ ret = open (arch_path, o_flags, 0); >> >> > >Er... automatically falling back to the host library? Why? > > I'm looking through solib_open() and trying to recreate my reasoning. It certainly seemed like a good idea at the time. Let's say the linker has the library as /home/kewarken/libfoo.so. Given the current solib_open, I don't believe that gdb will find it without having solib-search-path set. I put that there as a 'just in case' thing because a) it works well on self hosted and b) even for remote debugging, we often match the host and target filesystems. I figured that all common libs like libc.so, etc. would have been caught by the openp() above so the odds of accidentally getting a host library are slim. This makes things a bit easier for the user: the linker fills in the full path and gdb uses it rather than requiring a solib-search-path. cheers, Kris