From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28163 invoked by alias); 14 Apr 2009 17:32:57 -0000 Received: (qmail 28152 invoked by uid 22791); 14 Apr 2009 17:32:55 -0000 X-SWARE-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,BAYES_05,RCVD_IN_JMF_BL,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout5.012.net.il (HELO mtaout5.012.net.il) (84.95.2.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 14 Apr 2009 17:32:46 +0000 Received: from conversion-daemon.i_mtaout5.012.net.il by i_mtaout5.012.net.il (HyperSendmail v2004.12) id <0KI300F00PZTX400@i_mtaout5.012.net.il> for gdb-patches@sourceware.org; Tue, 14 Apr 2009 20:32:11 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.229.34.97]) by i_mtaout5.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KI3002M8Q1MZRA0@i_mtaout5.012.net.il>; Tue, 14 Apr 2009 20:32:11 +0300 (IDT) Date: Tue, 14 Apr 2009 17:32:00 -0000 From: Eli Zaretskii Subject: Setting up GDB init files broken in DJGPP To: Daniel Jacobowitz , Jerome Guitton Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83ljq3m999.fsf@gnu.org> 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-04/txt/msg00266.txt.bz2 AFAICS, this change: 2009-01-28 Daniel Jacobowitz Jerome Guitton * configure, config.in: Regenerated. * configure.ac: Add --with-system-gdbinit. * main.c (get_init_files): New. (captured_main): Use get_init_files. Load system gdbinit before $HOME/.gdbinit. (print_gdb_help): Print location of init files. broke the DJGPP port, in that it now looks for ~/.gdbinit rather than ~/gdb.ini. (The former is an invalid file name on DOS filesystems.) So all the gdb.ini files, such as the ones generated while building GDB and Emacs, are no longer sourced. The problem is that the change not only introduced a new function get_init_files and moved the code that looked up the gdbinit file(s) there from captured_main, but it also caused the code which looks for these files to be run _before_ initialize_all_files (which is called inside gdb_init). In fact, it moved the code even before the command-line arguments are parsed and acted upon. The DJGPP build overrides the default value of gdbinit, assigned in top.c from GDBINIT_FILENAME, inside init_go32_ops, but that is called in initialize_all_files, which now is too late. I've re-read the discussion about this change back in last December, and I couldn't find anything there that would explain why the order of the code execution was changed. Can someone tell whether there were such reasons, and if so, what they were? If not, perhaps simply moving the code after the call to gdb_init is all that's needed to fix this. TIA