From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5745 invoked by alias); 6 Oct 2009 09:33:55 -0000 Received: (qmail 5642 invoked by uid 22791); 6 Oct 2009 09:33:54 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 06 Oct 2009 09:33:50 +0000 Received: (qmail 23379 invoked from network); 6 Oct 2009 09:33:48 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 6 Oct 2009 09:33:48 -0000 From: Pedro Alves To: Doug Evans Subject: Re: Can we make gdbinit.in set the data-directory to @srcdir@? Date: Tue, 06 Oct 2009 09:33:00 -0000 User-Agent: KMail/1.9.10 Cc: =?iso-8859-1?q?S=E9rgio_Durigan_J=FAnior?= , gdb-patches@sourceware.org, Joel Brobecker References: <200910022056.30734.pedro@codesourcery.com> <200910060144.08110.sergiodj@linux.vnet.ibm.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910061033.52216.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-10/txt/msg00123.txt.bz2 On Tuesday 06 October 2009 06:34:39, Doug Evans wrote: > I think data-dir *is* set on start up, and we want it to. > > The testcase should set data-dir to something appropriate instead of > assuming what it is (or isn't). Yes. > Maybe the testcase could set data-dir to something that doesn't exist > when testing for non-existent xml files, etc. Yes. > Since the syscall files aren't read until the first request, one can > set data-dir to a non-existent directory first, and then do "catch > syscall". FTR, there are a few issues with when is the syscall file read. First, when the user changes the data-directory, gdb doesn't try to re-read the syscall file. This means no ammount of "set data-directory" to point at the real data directory path fixes "catch syscall" after gdb having noticed it didn't find the xml once. Second, the syscall file and the syscall name mappings aren't associated with gdbarch, they're global. This means that e.g., a gdb configured with native linux debugging support connected to a !linux remote target of linux remote target !arch than the native target mistakingly uses the native syscall name mapping. I'll probably file PRs for these. -- Pedro Alves