From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10627 invoked by alias); 25 Nov 2005 18:33:58 -0000 Received: (qmail 10620 invoked by uid 22791); 25 Nov 2005 18:33:57 -0000 X-Spam-Check-By: sourceware.org Received: from lon-del-02.spheriq.net (HELO lon-del-02.spheriq.net) (195.46.50.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 25 Nov 2005 18:33:55 +0000 Received: from lon-out-01.spheriq.net ([195.46.50.129]) by lon-del-02.spheriq.net with ESMTP id jAPIXqhP016653 for ; Fri, 25 Nov 2005 18:33:52 GMT Received: from lon-cus-01.spheriq.net (lon-cus-01.spheriq.net [195.46.50.37]) by lon-out-01.spheriq.net with ESMTP id jAPIXp4R026662 for ; Fri, 25 Nov 2005 18:33:52 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-01.spheriq.net with ESMTP id jAPIXoS1005072 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 25 Nov 2005 18:33:51 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 7CE1CDA45; Fri, 25 Nov 2005 18:33:50 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 119E747522; Fri, 25 Nov 2005 18:36:53 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id C30AA75995; Fri, 25 Nov 2005 18:36:52 +0000 (UTC) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 463254748C; Fri, 25 Nov 2005 18:36:52 +0000 (GMT) Received: from [164.129.15.13] (terrorhawk.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.5.8-GR) with ESMTP id CHA04930 (AUTH "andrew stubbs"); Fri, 25 Nov 2005 18:33:49 GMT Message-ID: <4387585E.9050302@st.com> Date: Fri, 25 Nov 2005 20:12:00 -0000 From: Andrew STUBBS User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Use search path for scripts References: <437B6718.7070300@st.com> <437C6D69.1030209@st.com> <437DC94B.7060601@st.com> <437DE8F9.9030606@st.com> <20051125175735.GB736@nevyn.them.org> <438752FE.9070302@st.com> <20051125181735.GF736@nevyn.them.org> In-Reply-To: <20051125181735.GF736@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-O-Spoofed: Not Scanned X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 4.2.0 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00466.txt.bz2 Daniel Jacobowitz wrote: > ... what? > > It's the source search path because that's what it's used for. It's > also documented that way: > > `-directory DIRECTORY' > `-d DIRECTORY' > Add DIRECTORY to the path to search for source files. My patch includes a modification to this documentation to reflect it's update purpose. > Most users don't ever have to add a source path. If you're using a > modern compiler, and debugging something built locally, and not using > certain kinds of include path constructs (which is unambiguously an > open, and recently discussed, bug in GDB) then GDB will Just Find > Things. That hasn't changed. The compiler can't tell the debugger where to find its script files though. > I don't find it intuitive that the same path should be overloaded this > way, and it makes changing the source searching algorithm even more > complicated. However, I'd like to know if any other GDB maintainers > have an opinion on this before I ask you to modify the patch. I'm not sure a users find it intuitive when they tell a tool to search a directory and then it ignores that directory because there was another way to tell the tool to search that directory, IYSWIM. I see your point about changing the search algorithm though. Although even then, it might be more intuitive to always use the same algorithm for both. Is it likely to change? Whatever though, as long as I get a way to search for script files I'm not that fussed. Andrew