Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: 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
Subject: Re: one week to gdb-7.6 release?
Date: Mon, 25 Mar 2013 17:46:00 -0000	[thread overview]
Message-ID: <83k3ov1mo0.fsf@gnu.org> (raw)
In-Reply-To: <20130325151825.GJ5447@adacore.com>

> 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.


  reply	other threads:[~2013-03-25 16:14 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-20 16:09 Joel Brobecker
2013-03-20 16:14 ` Pedro Alves
2013-03-20 17:06 ` Jan Kratochvil
2013-03-20 17:08 ` Joel Sherrill
2013-03-20 17:20 ` Eli Zaretskii
2013-03-23 22:59   ` Eli Zaretskii
2013-03-24  0:01     ` Joel Brobecker
2013-03-24  0:07       ` Eli Zaretskii
2013-03-25 16:58         ` Joel Brobecker
2013-03-25 17:46           ` Eli Zaretskii [this message]
2013-03-25 18:10             ` Joel Brobecker
2013-03-29  8:02               ` Joel Brobecker
2013-03-29 14:03                 ` Eli Zaretskii
2013-03-29 19:53                   ` Joel Brobecker
2013-04-02 18:05                   ` Eli Zaretskii
2013-04-05 13:03                     ` Eli Zaretskii
2013-04-06  6:16                       ` unbreak Windows hosted cross debugger builds (was: Re: one week to gdb-7.6 release?) Pedro Alves
2013-04-06 15:41                         ` unbreak Windows hosted cross debugger builds " Eli Zaretskii
2013-03-29 15:23                 ` one week to gdb-7.6 release? Ralf Corsepius
2013-03-29 16:42                   ` m32r sim was " Joel Sherrill
2013-03-29 17:18                     ` Mike Frysinger
2013-03-29 19:53                       ` Joel Brobecker
2013-03-29 20:24                         ` Joel Sherrill
2013-03-29 21:44                           ` Joel Brobecker
2013-04-04 13:03                         ` Ralf Corsepius
2013-04-10 15:01                           ` Joel Brobecker
2013-03-25 19:08             ` Mark Kettenis
2013-03-25 19:12               ` Eli Zaretskii
2013-04-06 21:49                 ` Pedro Alves
2013-04-07  3:58                   ` Eli Zaretskii
2013-03-23 23:38   ` Joel Sherrill
2013-03-24  0:12     ` Mike Frysinger
2013-03-20 18:23 ` Ralf Corsepius
2013-04-01 19:56 ` Mike Frysinger
2013-03-29 12:53 Joel Sherrill
2013-03-29 14:15 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83k3ov1mo0.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=joel.sherrill@oarcorp.com \
    --cc=palves@redhat.com \
    --cc=ralf.corsepius@rtems.org \
    --cc=vapier@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox