From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16759 invoked by alias); 14 Dec 2008 12:46:29 -0000 Received: (qmail 16749 invoked by uid 22791); 14 Dec 2008 12:46:29 -0000 X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (212.99.106.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 14 Dec 2008 12:45:54 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 18157290091 for ; Sun, 14 Dec 2008 13:45:51 +0100 (CET) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id if+Ag5sfwcyU for ; Sun, 14 Dec 2008 13:45:50 +0100 (CET) Received: from cardhu.act-europe.fr (cardhu.act-europe.fr [10.10.0.168]) by mel.act-europe.fr (Postfix) with ESMTP id 3BA5A29003C for ; Sun, 14 Dec 2008 13:45:50 +0100 (CET) Received: by cardhu.act-europe.fr (Postfix, from userid 560) id 0ECD61C9; Sun, 14 Dec 2008 13:45:49 +0100 (CET) Date: Sun, 14 Dec 2008 12:46:00 -0000 From: Jerome Guitton To: gdb@sourceware.org Subject: global, target-specific, init files Message-ID: <20081214124549.GA25544@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00055.txt.bz2 Hello everyone, I'd like to have your opinion about the utility of a couple of features that we are considering to implement in AdaCore. This mostly has to do with improvement to the init file. Here are the two features that we are missing: 1) target-specific settings: .gdbinit does not make it easy to have some settings/commands that should be executed for a particular system/target. Let me give an example to clarify this claim: suppose that, on a linux host, you build and debug both native applications and cross applications. Let's say that the cross target is some real-time flavour of linux. When you run the cross gdb, you would have to do a couple of "set solib-search-path"/"set solib-absolute-path" commands after starting the debugger, in order to debug with the appropriate libc/threads... You would like to have it done automatically, by .gdbinit; I may be wrong, but I do not know any way to execute a set of commands only when the cross debugger is executed. Or maybe there is a way to test the configure target? 2) global, "user-independant", init file: At startup, gdb will load the user-specific gdbinit (in $HOME) and the local gdbinit (in current dir); before these two files, it would be useful to load an init file that is valid for several users. Take the example I gave before, and suppose now that a sysadmin has to install the cross gdb I was describing and would like to make sure that the programmers will have the "set solib" commands executed before they actually use the debugger. He can of course document the issue, ask these programmers to modify their own user-specific gdbinit to include these commands... but I am pretty sure that it would prefer to have it done in some general config file (say /etc/gdbinit). To deal with these two problems, here is what I would suggest: 1) Have target-specific gdb init files, named after the configure target name (e.g. .powerpc-elf-gdbinit). .gdbinit would be the target-independant gdb init file; 2) Have "global" init files located in /etc (if the gdb executable is installed in /bin; would be re-computed by gdb at run time, just like gcc does for GCC_PREFIX). In other words, here is what GDB would do at startup: 1. Sets up the command interpreter as specified by the command line. 2. Reads the global target-independant init file (if any) in /etc (e.g. /etc/gdinit) and executes all the commands in that file. 3. Reads the global target-specific init file (if any) in /etc (e.g. /etc/powerpc-elf-gdinit) and executes all the commands in that file. 4. Reads and executes the target-independant and target-specific init files (if any) in your home directory. 3. Processes command line options and operands. 4. Reads and executes the commands from init files (if any) in the current working directory. 5. Reads command files specified by the `-x' option. 6. Reads the command history recorded in the history file. I would take care of proposing a patch if/when we reach an agreement. Opinions/thoughts? Thanks, Jerome