From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19659 invoked by alias); 25 Mar 2013 16:14:55 -0000 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 Received: (qmail 19611 invoked by uid 89); 25 Mar 2013 16:14:48 -0000 Received: from mtaout21.012.net.il (HELO mtaout21.012.net.il) (80.179.55.169) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 25 Mar 2013 16:14:48 +0000 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MK80050053UX700@a-mtaout21.012.net.il> for gdb-patches@sourceware.org; Mon, 25 Mar 2013 18:14:44 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MK80058554KST90@a-mtaout21.012.net.il>; Mon, 25 Mar 2013 18:14:44 +0200 (IST) Date: Mon, 25 Mar 2013 17:46:00 -0000 From: Eli Zaretskii Subject: Re: one week to gdb-7.6 release? In-reply-to: <20130325151825.GJ5447@adacore.com> To: Joel Brobecker Cc: gdb-patches@sourceware.org, palves@redhat.com, jan.kratochvil@redhat.com, ralf.corsepius@rtems.org, vapier@gentoo.org, joel.sherrill@oarcorp.com Reply-to: Eli Zaretskii Message-id: <83k3ov1mo0.fsf@gnu.org> References: <20130320160032.GC5447@adacore.com> <83vc8myoyb.fsf@gnu.org> <83ehf64cfs.fsf@gnu.org> <20130323162534.GI5447@adacore.com> <834ng23soj.fsf@gnu.org> <20130325151825.GJ5447@adacore.com> X-SW-Source: 2013-03/txt/msg00940.txt.bz2 > Date: Mon, 25 Mar 2013 08:18:26 -0700 > From: Joel Brobecker > Cc: gdb-patches@sourceware.org, palves@redhat.com, > jan.kratochvil@redhat.com, ralf.corsepius@rtems.org, > vapier@gentoo.org, joel.sherrill@oarcorp.com > > > > I think that the standard approach in this case would be to define > > > a function in utils.h, and have its implementation in both posix-hdep.c > > > and mingw-hdep.c. > > > > What would the implementation in posix-hdep.c look like? Just return > > its argument, xstrdup'ed? > > That would be a good start indeed. But then why do we need an implementation in posix-hdep.c at all? The code in main.c already does #ifdef __MINGW32__ /* On Windows, argv[0] is not necessarily set to absolute form when GDB is found along PATH, without which relocation doesn't work. */ gdb_program_name = windows_get_absolute_argv0 (argv[0]); #else gdb_program_name = xstrdup (argv[0]); #endif Is moving that to posix-hdep.c just to avoid an ifdef? That'd be OK, but then I'm not sure posix-hdep.c is being compiled into any port that isn't MinGW-hosted. Is it? E.g., what about the go32 port, just to pick up something really exotic? (Btw, the need and intended use of mingw-hdep.c and posix-hdep.c could really use some documentation, if only in the commentary at the beginning of those files. Right now, they both have the same(??) vague phrase there, which only adds to confusion.) > We could possibly think of testing > that the argument is an absolute path and then apply an xfullpath on > it if not xfullpath is not appropriate here, as it uses the current working directory, not the directory of the GDB executable file. > What I would do is add a comment inside the posix implementation that > the current use of this function is such that returning a copy of > the argument is sufficient. That way, someone finding that the function > finally needs to be implemented will understand the history. I think on Posix platforms, the way to convert argv[0] to an absolute file name is to search PATH.