This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: one week to gdb-7.6 release?
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org, palves at redhat dot com, jan dot kratochvil at redhat dot com, ralf dot corsepius at rtems dot org, vapier at gentoo dot org, joel dot sherrill at oarcorp dot com
- Date: Mon, 25 Mar 2013 18:14:55 +0200
- Subject: Re: one week to gdb-7.6 release?
- References: <20130320160032 dot GC5447 at adacore dot com> <83vc8myoyb dot fsf at gnu dot org> <83ehf64cfs dot fsf at gnu dot org> <20130323162534 dot GI5447 at adacore dot com> <834ng23soj dot fsf at gnu dot org> <20130325151825 dot GJ5447 at adacore dot com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Mon, 25 Mar 2013 08:18:26 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> 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.