Re: one week to gdb-7.6 release?

Re: one week to gdb-7.6 release?

[Joel Sherrill]

Does this mean that you can't build a mingw hosted cross compiler either natively on mingw or via Canadian cross?

If so, I would consider that a serious regression and blocker.

If I read your comment correctly, you consider it a blocker also.

And is there a list somewhere of mingw issues? Like dv-socker.o, simulators using POSIX signals and termios, etc.. Seems like a good GSOC project.

--joel
RTEMS

Joel Brobecker <brobecker@adacore.com> wrote:


> > 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?
>
> The main purpose is to move the code away out of windows-nat, which
> is only linked in native debuggers, not cross ones - so that building
> a cross debugger hosted on Windows will work again. Basically, your
> new function is really only dependent on the host, whereas the -nat
> file makes the assumption that host & target are Windows.

I have added this item to the TODO list for the 7.6 release, so as not
to forget.

I was wondering if this discussion was stalled, or if it was just
a matter of not finding the time to do the implementation. I could
possibly take care of it tomorrow if you'd like.  There is not real
rush, however, as I will be off next week, and thus unable to create
a release at least until Tue Apr 9th.

--
Joel

Re: one week to gdb-7.6 release?

[Eli Zaretskii]

> From: Joel Sherrill <Joel.Sherrill@OARcorp.com>
> CC: Eli Zaretskii <eliz@gnu.org>, "gdb-patches@sourceware.org"
> 	<gdb-patches@sourceware.org>, "vapier@gentoo.org" <vapier@gentoo.org>, Chris
>  Johns <chrisj@rtems.org>
> Date: Thu, 28 Mar 2013 21:08:33 -0500
> Accept-Language: en-US
> acceptlanguage: en-US
> 
> Does this mean that you can't build a mingw hosted cross compiler either natively on mingw or via Canadian cross?
> 
> If so, I would consider that a serious regression and blocker.

It's not a blocker, because those changes were not committed to the
release branch.  It _is_ a regression on the trunk, sorry about that.

The issue will be fixed in a few days.

one week to gdb-7.6 release?

[Joel Brobecker]

Hello,

We're about one week away from our tentative date for gdb-7.6 release,
and I was wondering how we are doing, and whether there might be
some issues that might prevent us from releasing around our planned
date.

I know of:

  * PR/15289 set remote hardware-watchpoint-limit" broken (zinteger commands)
    (regression)
    Easy to fix, or just revert the patch that caused the regression?

  * dv-sockser.o build issues in the sim.
    Looks like the thread lost steam a bit - can we stoke the fire again?

Jan, not sure if some of the patches you posted for 7.6 are still
pending?

Thanks!
-- 
Joel

Re: one week to gdb-7.6 release?

[Pedro Alves]

On 03/20/2013 04:00 PM, Joel Brobecker wrote:

> I know of:
> 
>   * PR/15289 set remote hardware-watchpoint-limit" broken (zinteger commands)
>     (regression)
>     Easy to fix, or just revert the patch that caused the regression?

I'm testing a fix.

-- 
Pedro Alves

Re: one week to gdb-7.6 release?

[Jan Kratochvil]

On Wed, 20 Mar 2013 17:00:32 +0100, Joel Brobecker wrote:
> Jan, not sure if some of the patches you posted for 7.6 are still
> pending?

I have added to http://sourceware.org/gdb/wiki/GDB_7.6_Release:
TODO+=
	[Jan] Fix 7.5 regression crashing GDB if gdbserver dies
	      http://sourceware.org/ml/gdb-patches/2013-03/msg00691.html
	[Jan] Fix remote.c incorrectly using pop_target (wrt btrace)
	      http://sourceware.org/ml/gdb-patches/2013-03/msg00692.html

But these will just get checked in soon.

I do not know about any blockers to work on.


Thanks,
Jan

Re: one week to gdb-7.6 release?

[Joel Sherrill]

On 3/20/2013 11:00 AM, Joel Brobecker wrote:
> Hello,
>
> We're about one week away from our tentative date for gdb-7.6 release,
> and I was wondering how we are doing, and whether there might be
> some issues that might prevent us from releasing around our planned
> date.
>
> I know of:
>
>    * PR/15289 set remote hardware-watchpoint-limit" broken (zinteger commands)
>      (regression)
>      Easy to fix, or just revert the patch that caused the regression?
>
>    * dv-sockser.o build issues in the sim.
>      Looks like the thread lost steam a bit - can we stoke the fire again?
>
I am sorry. I am at an Open Group meeting this week and couldn't get a 
checkout
until sourceware.org's hardware upgrade got source code repos available 
again.

I just did a git clone and am working through the issues.  I plan to send a
patch to common plus one per target simulator. Hopefully that will make
it easier to review and approve.
> Jan, not sure if some of the patches you posted for 7.6 are still
> pending?
>
> Thanks!


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: one week to gdb-7.6 release?

[Eli Zaretskii]

> Date: Wed, 20 Mar 2013 09:00:32 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Pedro Alves <palves@redhat.com>,	Jan Kratochvil <jan.kratochvil@redhat.com>,	Ralf Corsepius <ralf.corsepius@rtems.org>,	Mike Frysinger <vapier@gentoo.org>,	Joel Sherrill <joel.sherrill@oarcorp.com>
> 
> We're about one week away from our tentative date for gdb-7.6 release,
> and I was wondering how we are doing, and whether there might be
> some issues that might prevent us from releasing around our planned
> date.
> 
> I know of:
> 
>   * PR/15289 set remote hardware-watchpoint-limit" broken (zinteger commands)
>     (regression)
>     Easy to fix, or just revert the patch that caused the regression?
> 
>   * dv-sockser.o build issues in the sim.
>     Looks like the thread lost steam a bit - can we stoke the fire again?

I'd like my patch that deals with relocation to be committed to the
branch.  I don't see it in the list archives, so cannot show a URL,
but Jan send a few comments that I want to incorporate and submit
tomorrow.

Re: one week to gdb-7.6 release?

[Eli Zaretskii]

> Date: Wed, 20 Mar 2013 19:13:16 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gdb-patches@sourceware.org, palves@redhat.com, jan.kratochvil@redhat.com, ralf.corsepius@rtems.org, vapier@gentoo.org, joel.sherrill@oarcorp.com
> 
> > Date: Wed, 20 Mar 2013 09:00:32 -0700
> > From: Joel Brobecker <brobecker@adacore.com>
> > Cc: Pedro Alves <palves@redhat.com>,	Jan Kratochvil <jan.kratochvil@redhat.com>,	Ralf Corsepius <ralf.corsepius@rtems.org>,	Mike Frysinger <vapier@gentoo.org>,	Joel Sherrill <joel.sherrill@oarcorp.com>
> > 
> > We're about one week away from our tentative date for gdb-7.6 release,
> > and I was wondering how we are doing, and whether there might be
> > some issues that might prevent us from releasing around our planned
> > date.
> > 
> > I know of:
> > 
> >   * PR/15289 set remote hardware-watchpoint-limit" broken (zinteger commands)
> >     (regression)
> >     Easy to fix, or just revert the patch that caused the regression?
> > 
> >   * dv-sockser.o build issues in the sim.
> >     Looks like the thread lost steam a bit - can we stoke the fire again?
> 
> I'd like my patch that deals with relocation to be committed to the
> branch.  I don't see it in the list archives, so cannot show a URL,
> but Jan send a few comments that I want to incorporate and submit
> tomorrow.

Committed to the trunk as below.  This incorporates comments from Jan.

OK to commit the same to the 7.6 branch?

2013-03-18  Eli Zaretskii  <eliz@gnu.org>

	* windows-nat.c (windows_get_absolute_argv0): New function.
	* windows-nat.h: Add its prototype.

	* main.c (get_init_files): Use filename_ncmp instead of strncmp.
	Use IS_DIR_SEPARATOR instead of looking for a character inside
	SLASH_STRING.  Include filenames.h.
	(captured_main) [__MINGW32__]: Make argv[0] absolute, so that
	relocate_gdb_directory works when passed gdb_program_name.
	Include windows-nat.h.


--- gdb/main.c~0	2013-01-25 02:46:19.000000000 +0200
+++ gdb/main.c	2013-03-21 19:11:12.039633400 +0200
@@ -43,6 +43,11 @@
 #include "objfiles.h"
 #include "auto-load.h"
 
+#include "filenames.h"
+#ifdef __MINGW32__
+# include "windows-nat.h"
+#endif
+
 /* The selected interpreter.  This will be used as a set command
    variable, so it should always be malloc'ed - since
    do_setshow_command will free it.  */
@@ -180,15 +185,15 @@ get_init_files (char **system_gdbinit,
 	     has been provided, search for SYSTEM_GDBINIT there.  */
 	  if (gdb_datadir_provided
 	      && datadir_len < sys_gdbinit_len
-	      && strncmp (SYSTEM_GDBINIT, GDB_DATADIR, datadir_len) == 0
-	      && strchr (SLASH_STRING, SYSTEM_GDBINIT[datadir_len]) != NULL)
+	      && filename_ncmp (SYSTEM_GDBINIT, GDB_DATADIR, datadir_len) == 0
+	      && IS_DIR_SEPARATOR (SYSTEM_GDBINIT[datadir_len]))
 	    {
 	      /* Append the part of SYSTEM_GDBINIT that follows GDB_DATADIR
 		 to gdb_datadir.  */
 	      char *tmp_sys_gdbinit = xstrdup (SYSTEM_GDBINIT + datadir_len);
 	      char *p;
 
-	      for (p = tmp_sys_gdbinit; strchr (SLASH_STRING, *p); ++p)
+	      for (p = tmp_sys_gdbinit; IS_DIR_SEPARATOR (*p); ++p)
 		continue;
 	      relocated_sysgdbinit = concat (gdb_datadir, SLASH_STRING, p,
 					     NULL);
@@ -377,7 +382,13 @@ captured_main (void *data)
   gdb_stdtargerr = gdb_stderr;	/* for moment */
   gdb_stdtargin = gdb_stdin;	/* for moment */
 
+#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
 
   if (! getcwd (gdb_dirbuf, sizeof (gdb_dirbuf)))
     /* Don't use *_filtered or warning() (which relies on
@@ -411,7 +422,7 @@ captured_main (void *data)
 
 #ifdef RELOC_SRCDIR
   add_substitute_path_rule (RELOC_SRCDIR,
-			    make_relative_prefix (argv[0], BINDIR,
+			    make_relative_prefix (gdb_program_name, BINDIR,
 						  RELOC_SRCDIR));
 #endif
 
@@ -729,7 +740,7 @@ captured_main (void *data)
 
   /* Initialize all files.  Give the interpreter a chance to take
      control of the console via the deprecated_init_ui_hook ().  */
-  gdb_init (argv[0]);
+  gdb_init (gdb_program_name);
 
   /* Now that gdb_init has created the initial inferior, we're in
      position to set args for that inferior.  */


--- gdb/windows-nat.c~0	2013-02-27 21:42:26.000000000 +0200
+++ gdb/windows-nat.c	2013-03-21 19:05:21.642985800 +0200
@@ -597,6 +597,18 @@ failed:
   return 0;		/* failure */
 }
 
+/* Return an absolute file name of the running GDB, if possible, or
+   ARGV0 if not.  The return value is in malloc'ed storage.  */
+char *
+windows_get_absolute_argv0 (const char *argv0)
+{
+  char full_name[PATH_MAX];
+
+  if (GetModuleFileName (NULL, full_name, PATH_MAX))
+    return xstrdup (full_name);
+  return xstrdup (argv0);
+}
+
 /* Encapsulate the information required in a call to
    symbol_file_add_args.  */
 struct safe_symbol_file_add_args


--- gdb/windows-nat.h~0	2013-02-12 21:03:54.000000000 +0200
+++ gdb/windows-nat.h	2013-03-21 19:05:19.068969300 +0200
@@ -28,5 +28,9 @@
    whether a given register is a segment register or not.  */
 extern void windows_set_segment_register_p (segment_register_p_ftype *fun);
 
+/* Return argv[0] in absolute form, if possible, or ARGV0 if not.  The
+   return value is in malloc'ed storage.  */
+extern char *windows_get_absolute_argv0 (const char *argv0);
+
 #endif
 

Re: one week to gdb-7.6 release?

[Joel Brobecker]

Hi Eli,

> Committed to the trunk as below.  This incorporates comments from Jan.
> OK to commit the same to the 7.6 branch?

> 2013-03-18  Eli Zaretskii  <eliz@gnu.org>
> 
> 	* windows-nat.c (windows_get_absolute_argv0): New function.
> 	* windows-nat.h: Add its prototype.
> 
> 	* main.c (get_init_files): Use filename_ncmp instead of strncmp.
> 	Use IS_DIR_SEPARATOR instead of looking for a character inside
> 	SLASH_STRING.  Include filenames.h.
> 	(captured_main) [__MINGW32__]: Make argv[0] absolute, so that
> 	relocate_gdb_directory works when passed gdb_program_name.
> 	Include windows-nat.h.

I think that the patch, as is, breaks the windows-hosted cross-debugger
builds. windows-nat.o is only linked in when configured as a native
debugger:

   if test "${gdb_native}" = "yes"; then
     host_makefile_frag=${srcdir}/config/${gdb_host_cpu}/${gdb_host}.mh

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.

A minor nitpick on coding style: Can you add an empty line between
the comment documenting a function ands its definition?

Thank you,
-- 
Joel

Re: one week to gdb-7.6 release?

[Eli Zaretskii]

> Date: Sat, 23 Mar 2013 09:25:34 -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
> 
> > 2013-03-18  Eli Zaretskii  <eliz@gnu.org>
> > 
> > 	* windows-nat.c (windows_get_absolute_argv0): New function.
> > 	* windows-nat.h: Add its prototype.
> > 
> > 	* main.c (get_init_files): Use filename_ncmp instead of strncmp.
> > 	Use IS_DIR_SEPARATOR instead of looking for a character inside
> > 	SLASH_STRING.  Include filenames.h.
> > 	(captured_main) [__MINGW32__]: Make argv[0] absolute, so that
> > 	relocate_gdb_directory works when passed gdb_program_name.
> > 	Include windows-nat.h.
> 
> I think that the patch, as is, breaks the windows-hosted cross-debugger
> builds. windows-nat.o is only linked in when configured as a native
> debugger:
> 
>    if test "${gdb_native}" = "yes"; then
>      host_makefile_frag=${srcdir}/config/${gdb_host_cpu}/${gdb_host}.mh
> 
> 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?

> A minor nitpick on coding style: Can you add an empty line between
> the comment documenting a function ands its definition?

I don't mind, but this style is not uniformly used in the sources.
Quite a few places don't leave that empty line.  (I'm accustomed to
the latter, which is why I used that.)

Re: one week to gdb-7.6 release?

[Joel Brobecker]

> > 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. We could possibly think of testing
that the argument is an absolute path and then apply an xfullpath on
it if not, but we'd be taking a risk of causing a change in behavior.
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.

> > A minor nitpick on coding style: Can you add an empty line between
> > the comment documenting a function ands its definition?
> 
> I don't mind, but this style is not uniformly used in the sources.
> Quite a few places don't leave that empty line.  (I'm accustomed to
> the latter, which is why I used that.)

I understand where you are coming from. This is based on a discussion
we had on this, and we decided to standardize on the former. It really
does not matter to me either way, but I try to help us improve our
consistency...

-- 
Joel

Re: one week to gdb-7.6 release?

[Eli Zaretskii]

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

Re: one week to gdb-7.6 release?

[Joel Brobecker]

> But then why do we need an implementation in posix-hdep.c at all?

I did not mean to say that we do need an implementation in posix-hdep,
just saying that we might someday in the future - and if we do, a
comment explaining the currrent implemention would help the next person
looking at it.

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

The main purpose is to move the code away out of windows-nat, which
is only linked in native debuggers, not cross ones - so that building
a cross debugger hosted on Windows will work again. Basically, your
new function is really only dependent on the host, whereas the -nat
file makes the assumption that host & target are Windows.

-- 
Joel

Re: one week to gdb-7.6 release?

[Joel Brobecker]

> > 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?
> 
> The main purpose is to move the code away out of windows-nat, which
> is only linked in native debuggers, not cross ones - so that building
> a cross debugger hosted on Windows will work again. Basically, your
> new function is really only dependent on the host, whereas the -nat
> file makes the assumption that host & target are Windows.

I have added this item to the TODO list for the 7.6 release, so as not
to forget.

I was wondering if this discussion was stalled, or if it was just
a matter of not finding the time to do the implementation. I could
possibly take care of it tomorrow if you'd like.  There is not real
rush, however, as I will be off next week, and thus unable to create
a release at least until Tue Apr 9th.

-- 
Joel

Re: one week to gdb-7.6 release?

[Eli Zaretskii]

> Date: Thu, 28 Mar 2013 18:59:24 -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
> 
> > > 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?
> > 
> > The main purpose is to move the code away out of windows-nat, which
> > is only linked in native debuggers, not cross ones - so that building
> > a cross debugger hosted on Windows will work again. Basically, your
> > new function is really only dependent on the host, whereas the -nat
> > file makes the assumption that host & target are Windows.
> 
> I have added this item to the TODO list for the 7.6 release, so as not
> to forget.

Thanks.

> I was wondering if this discussion was stalled, or if it was just
> a matter of not finding the time to do the implementation.

The latter.

> I could possibly take care of it tomorrow if you'd like.

If you have time, it's fine with me.  Failing that, I will submit the
changes in a few days.

Re: one week to gdb-7.6 release?

[Joel Brobecker]

> > I could possibly take care of it tomorrow if you'd like.
> 
> If you have time, it's fine with me.  Failing that, I will submit the
> changes in a few days.

OK. I was saying that I am off all of next week, and I doubt I will
have much time before that. If you can't do it next week also, I will
take care of it as soon as I return.

Thanks, Eli.
-- 
Joel

Re: one week to gdb-7.6 release?

[Eli Zaretskii]

> Date: Fri, 29 Mar 2013 08:56:41 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gdb-patches@sourceware.org, palves@redhat.com, jan.kratochvil@redhat.com, ralf.corsepius@rtems.org, vapier@gentoo.org, joel.sherrill@oarcorp.com
> 
> > Date: Thu, 28 Mar 2013 18:59:24 -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
> > 
> > > > 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?
> > > 
> > > The main purpose is to move the code away out of windows-nat, which
> > > is only linked in native debuggers, not cross ones - so that building
> > > a cross debugger hosted on Windows will work again. Basically, your
> > > new function is really only dependent on the host, whereas the -nat
> > > file makes the assumption that host & target are Windows.
> > 
> > I have added this item to the TODO list for the 7.6 release, so as not
> > to forget.
> 
> Thanks.
> 
> > I was wondering if this discussion was stalled, or if it was just
> > a matter of not finding the time to do the implementation.
> 
> The latter.
> 
> > I could possibly take care of it tomorrow if you'd like.
> 
> If you have time, it's fine with me.  Failing that, I will submit the
> changes in a few days.

Here they are.  This is for the trunk; it undoes the previous commit
and moves the code to mingw-hdep.c.

OK to commit, including the branch (which will get a different change,
since there's no need to remove the previous commit there)?

2013-04-02  Eli Zaretskii  <eliz@gnu.org>

	* windows-nat.c (windows_get_absolute_argv0): Move from here...
	* mingw-hdep.c (windows_get_absolute_argv0): ...to here.
	Include main.h.

	* windows-nat.h (windows_get_absolute_argv0): Move prototype from
	here...
	* main.h (windows_get_absolute_argv0): ...to here

--- gdb/windows-nat.c~1	2013-03-21 13:05:21.642985800 +0200
+++ gdb/windows-nat.c	2013-04-02 20:04:56.438612100 +0300
@@ -597,18 +597,6 @@ failed:
   return 0;		/* failure */
 }
 
-/* Return an absolute file name of the running GDB, if possible, or
-   ARGV0 if not.  The return value is in malloc'ed storage.  */
-char *
-windows_get_absolute_argv0 (const char *argv0)
-{
-  char full_name[PATH_MAX];
-
-  if (GetModuleFileName (NULL, full_name, PATH_MAX))
-    return xstrdup (full_name);
-  return xstrdup (argv0);
-}
-
 /* Encapsulate the information required in a call to
    symbol_file_add_args.  */
 struct safe_symbol_file_add_args

--- gdb/windows-nat.h~1	2013-03-21 13:05:19.068969300 +0200
+++ gdb/windows-nat.h	2013-04-02 20:05:15.626735100 +0300
@@ -28,9 +28,5 @@ typedef int (segment_register_p_ftype) (
    whether a given register is a segment register or not.  */
 extern void windows_set_segment_register_p (segment_register_p_ftype *fun);
 
-/* Return argv[0] in absolute form, if possible, or ARGV0 if not.  The
-   return value is in malloc'ed storage.  */
-extern char *windows_get_absolute_argv0 (const char *argv0);
-
 #endif
 

--- gdb/mingw-hdep.c~1	2013-01-01 08:32:47.000000000 +0200
+++ gdb/mingw-hdep.c	2013-04-02 20:26:57.231081900 +0300
@@ -18,6 +18,7 @@
    along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
 
 #include "defs.h"
+#include "main.h"
 #include "serial.h"
 #include "event-loop.h"
 
@@ -80,6 +81,19 @@ safe_strerror (int errnum)
   return buffer;
 }
 
+/* Return an absolute file name of the running GDB, if possible, or
+   ARGV0 if not.  The return value is in malloc'ed storage.  */
+
+char *
+windows_get_absolute_argv0 (const char *argv0)
+{
+  char full_name[PATH_MAX];
+
+  if (GetModuleFileName (NULL, full_name, PATH_MAX))
+    return xstrdup (full_name);
+  return xstrdup (argv0);
+}
+
 /* Wrapper for select.  On Windows systems, where the select interface
    only works for sockets, this uses the GDB serial abstraction to
    handle sockets, consoles, pipes, and serial ports.

--- gdb/main.c~2	2013-03-21 13:11:43.279038500 +0200
+++ gdb/main.c	2013-04-02 20:07:51.534134500 +0300
@@ -44,9 +44,6 @@
 #include "auto-load.h"
 
 #include "filenames.h"
-#ifdef __MINGW32__
-# include "windows-nat.h"
-#endif
 
 #include "version.h"
 

--- gdb/main.h~1	2013-01-01 08:32:47.000000000 +0200
+++ gdb/main.h	2013-04-02 20:25:41.837731800 +0300
@@ -36,4 +36,10 @@ extern int return_child_result_value;
 extern int batch_silent;
 extern int batch_flag;
 
+/* From mingw-hdep.c, used by main.c.  */
+
+/* Return argv[0] in absolute form, if possible, or ARGV0 if not.  The
+   return value is in malloc'ed storage.  */
+extern char *windows_get_absolute_argv0 (const char *argv0);
+
 #endif

Re: one week to gdb-7.6 release?

[Eli Zaretskii]

> Date: Tue, 02 Apr 2013 20:33:00 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gdb-patches@sourceware.org, palves@redhat.com, jan.kratochvil@redhat.com

Ping!  OK to commit, mainline and 7.6 branch?

(Just 3 days have passed, but we have a release looming...)

> > Date: Fri, 29 Mar 2013 08:56:41 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: gdb-patches@sourceware.org, palves@redhat.com, jan.kratochvil@redhat.com, ralf.corsepius@rtems.org, vapier@gentoo.org, joel.sherrill@oarcorp.com
> > 
> > > Date: Thu, 28 Mar 2013 18:59:24 -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
> > > 
> > > > > 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?
> > > > 
> > > > The main purpose is to move the code away out of windows-nat, which
> > > > is only linked in native debuggers, not cross ones - so that building
> > > > a cross debugger hosted on Windows will work again. Basically, your
> > > > new function is really only dependent on the host, whereas the -nat
> > > > file makes the assumption that host & target are Windows.
> > > 
> > > I have added this item to the TODO list for the 7.6 release, so as not
> > > to forget.
> > 
> > Thanks.
> > 
> > > I was wondering if this discussion was stalled, or if it was just
> > > a matter of not finding the time to do the implementation.
> > 
> > The latter.
> > 
> > > I could possibly take care of it tomorrow if you'd like.
> > 
> > If you have time, it's fine with me.  Failing that, I will submit the
> > changes in a few days.
> 
> Here they are.  This is for the trunk; it undoes the previous commit
> and moves the code to mingw-hdep.c.
> 
> OK to commit, including the branch (which will get a different change,
> since there's no need to remove the previous commit there)?
> 
> 2013-04-02  Eli Zaretskii  <eliz@gnu.org>
> 
> 	* windows-nat.c (windows_get_absolute_argv0): Move from here...
> 	* mingw-hdep.c (windows_get_absolute_argv0): ...to here.
> 	Include main.h.
> 
> 	* windows-nat.h (windows_get_absolute_argv0): Move prototype from
> 	here...
> 	* main.h (windows_get_absolute_argv0): ...to here
> 
> --- gdb/windows-nat.c~1	2013-03-21 13:05:21.642985800 +0200
> +++ gdb/windows-nat.c	2013-04-02 20:04:56.438612100 +0300
> @@ -597,18 +597,6 @@ failed:
>    return 0;		/* failure */
>  }
>  
> -/* Return an absolute file name of the running GDB, if possible, or
> -   ARGV0 if not.  The return value is in malloc'ed storage.  */
> -char *
> -windows_get_absolute_argv0 (const char *argv0)
> -{
> -  char full_name[PATH_MAX];
> -
> -  if (GetModuleFileName (NULL, full_name, PATH_MAX))
> -    return xstrdup (full_name);
> -  return xstrdup (argv0);
> -}
> -
>  /* Encapsulate the information required in a call to
>     symbol_file_add_args.  */
>  struct safe_symbol_file_add_args
> 
> --- gdb/windows-nat.h~1	2013-03-21 13:05:19.068969300 +0200
> +++ gdb/windows-nat.h	2013-04-02 20:05:15.626735100 +0300
> @@ -28,9 +28,5 @@ typedef int (segment_register_p_ftype) (
>     whether a given register is a segment register or not.  */
>  extern void windows_set_segment_register_p (segment_register_p_ftype *fun);
>  
> -/* Return argv[0] in absolute form, if possible, or ARGV0 if not.  The
> -   return value is in malloc'ed storage.  */
> -extern char *windows_get_absolute_argv0 (const char *argv0);
> -
>  #endif
>  
> 
> --- gdb/mingw-hdep.c~1	2013-01-01 08:32:47.000000000 +0200
> +++ gdb/mingw-hdep.c	2013-04-02 20:26:57.231081900 +0300
> @@ -18,6 +18,7 @@
>     along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
>  
>  #include "defs.h"
> +#include "main.h"
>  #include "serial.h"
>  #include "event-loop.h"
>  
> @@ -80,6 +81,19 @@ safe_strerror (int errnum)
>    return buffer;
>  }
>  
> +/* Return an absolute file name of the running GDB, if possible, or
> +   ARGV0 if not.  The return value is in malloc'ed storage.  */
> +
> +char *
> +windows_get_absolute_argv0 (const char *argv0)
> +{
> +  char full_name[PATH_MAX];
> +
> +  if (GetModuleFileName (NULL, full_name, PATH_MAX))
> +    return xstrdup (full_name);
> +  return xstrdup (argv0);
> +}
> +
>  /* Wrapper for select.  On Windows systems, where the select interface
>     only works for sockets, this uses the GDB serial abstraction to
>     handle sockets, consoles, pipes, and serial ports.
> 
> --- gdb/main.c~2	2013-03-21 13:11:43.279038500 +0200
> +++ gdb/main.c	2013-04-02 20:07:51.534134500 +0300
> @@ -44,9 +44,6 @@
>  #include "auto-load.h"
>  
>  #include "filenames.h"
> -#ifdef __MINGW32__
> -# include "windows-nat.h"
> -#endif
>  
>  #include "version.h"
>  
> 
> --- gdb/main.h~1	2013-01-01 08:32:47.000000000 +0200
> +++ gdb/main.h	2013-04-02 20:25:41.837731800 +0300
> @@ -36,4 +36,10 @@ extern int return_child_result_value;
>  extern int batch_silent;
>  extern int batch_flag;
>  
> +/* From mingw-hdep.c, used by main.c.  */
> +
> +/* Return argv[0] in absolute form, if possible, or ARGV0 if not.  The
> +   return value is in malloc'ed storage.  */
> +extern char *windows_get_absolute_argv0 (const char *argv0);
> +
>  #endif
> 

Re: one week to gdb-7.6 release?

[Ralf Corsepius]

On 03/29/2013 02:59 AM, Joel Brobecker wrote:
> I was wondering if this discussion was stalled, or if it was just
> a matter of not finding the time to do the implementation.
Sorry, in my case, it's simply lack of time.

> I could
> possibly take care of it tomorrow if you'd like.  There is not real
> rush, however, as I will be off next week, and thus unable to create
> a release at least until Tue Apr 9th.

I just did a test-rebuild with current gdb-7_6-branch (presuming Joel's 
new patches are in).

Using the same set of configuration options, I have been using for 
gdb-7.5.x, all targets build fine on Linux.

However, there is a new breakdown for the m32r on mingw32-w64-{x86_64,i386}:

..../configure --build=i386-pc-linux-gnu \
--host=x86_64-w64-mingw32 --target=m32r-rtems4.11
--enable-sim [...] \
...
checking how to recognize dependent libraries... configure: error: 
Sorry, but hardware support in this simulator unconditionally
relies on dv-sockser.o which is unavailable for your host. Please fix 
this simulator.
...

As gdb-7.5.x built fine with the same configuration, this to me 
qualifies as a regression - Or is this just a latent, so far silently 
accepted, but dysfunctional part being revealed by the new configuration 
magic?

Ralf

Re: one week to gdb-7.6 release?

[Mark Kettenis]

> Date: Mon, 25 Mar 2013 18:14:55 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > 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.

Not really; argv[0] can be set to anything.  It's just convention that
it gets set to the name of the program being executed.

Re: one week to gdb-7.6 release?

[Eli Zaretskii]

> Date: Mon, 25 Mar 2013 17:27:43 +0100 (CET)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: brobecker@adacore.com, gdb-patches@sourceware.org, palves@redhat.com,        jan.kratochvil@redhat.com, ralf.corsepius@rtems.org, vapier@gentoo.org,        joel.sherrill@oarcorp.com
> 
> > Date: Mon, 25 Mar 2013 18:14:55 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > > 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.
> 
> Not really; argv[0] can be set to anything.  It's just convention that
> it gets set to the name of the program being executed.

Well, if it isn't set to the name of the program, and its leading
directory doesn't name the directory where the real GDB executable
lives, then relocation of directories simply cannot work, and
shouldn't be expected to.  I think we should only care about the use
cases where the pre-conditions for relocation do exist.

Re: one week to gdb-7.6 release?

[Pedro Alves]

On 03/25/2013 04:58 PM, Eli Zaretskii wrote:
>> From: Mark Kettenis <mark.kettenis@xs4all.nl>
>>> From: Eli Zaretskii <eliz@gnu.org>
>>> I think on Posix platforms, the way to convert argv[0] to an absolute
>>> file name is to search PATH.
>>
>> Not really; argv[0] can be set to anything.  It's just convention that
>> it gets set to the name of the program being executed.
> 
> Well, if it isn't set to the name of the program, and its leading
> directory doesn't name the directory where the real GDB executable
> lives, then relocation of directories simply cannot work, and
> shouldn't be expected to.  I think we should only care about the use
> cases where the pre-conditions for relocation do exist.

Replying mainly for the archives.  On Linux, we can always
readlink /proc/self/exe to figure out the full program path.
That steps out of Posix, of course.

An easy way to set the argv[0] to anything is with bash's exec
command:

$ (exec -a foo ./gdb)
...
(gdb) ^Z
[1]+  Stopped                 ( exec -a foo ./gdb )
$ pidof foo
27543
$ readlink /proc/27543/exe
/home/pedro/gdb/mygit/build/gdb/gdb

I'm not suggesting this is a use case we need to bother with.

-- 
Pedro Alves

Re: one week to gdb-7.6 release?

[Eli Zaretskii]

> Date: Sat, 06 Apr 2013 14:56:27 +0100
> From: Pedro Alves <palves@redhat.com>
> CC: Mark Kettenis <mark.kettenis@xs4all.nl>, brobecker@adacore.com,
>         gdb-patches@sourceware.org, jan.kratochvil@redhat.com,
>         ralf.corsepius@rtems.org, vapier@gentoo.org, joel.sherrill@oarcorp.com
> 
> On 03/25/2013 04:58 PM, Eli Zaretskii wrote:
> >> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> >>> From: Eli Zaretskii <eliz@gnu.org>
> >>> I think on Posix platforms, the way to convert argv[0] to an absolute
> >>> file name is to search PATH.
> >>
> >> Not really; argv[0] can be set to anything.  It's just convention that
> >> it gets set to the name of the program being executed.
> > 
> > Well, if it isn't set to the name of the program, and its leading
> > directory doesn't name the directory where the real GDB executable
> > lives, then relocation of directories simply cannot work, and
> > shouldn't be expected to.  I think we should only care about the use
> > cases where the pre-conditions for relocation do exist.
> 
> Replying mainly for the archives.  On Linux, we can always
> readlink /proc/self/exe to figure out the full program path.
> That steps out of Posix, of course.

Ideas for other platforms can be taken from the gnulib progreloc.c
file.

Re: one week to gdb-7.6 release?

[Joel Sherrill]

On 3/20/2013 12:13 PM, Eli Zaretskii wrote:
>> Date: Wed, 20 Mar 2013 09:00:32 -0700
>> From: Joel Brobecker <brobecker@adacore.com>
>> Cc: Pedro Alves <palves@redhat.com>,	Jan Kratochvil <jan.kratochvil@redhat.com>,	Ralf Corsepius <ralf.corsepius@rtems.org>,	Mike Frysinger <vapier@gentoo.org>,	Joel Sherrill <joel.sherrill@oarcorp.com>
>>
>> We're about one week away from our tentative date for gdb-7.6 release,
>> and I was wondering how we are doing, and whether there might be
>> some issues that might prevent us from releasing around our planned
>> date.
>>
>> I know of:
>>
>>    * PR/15289 set remote hardware-watchpoint-limit" broken (zinteger commands)
>>      (regression)
>>      Easy to fix, or just revert the patch that caused the regression?
>>
>>    * dv-sockser.o build issues in the sim.
>>      Looks like the thread lost steam a bit - can we stoke the fire again?
>
I just committed the dv-sockser.o fix to the 4.6 branch and head.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: one week to gdb-7.6 release?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 334 bytes --]

On Saturday 23 March 2013 11:13:57 Joel Sherrill wrote:
> >>    * dv-sockser.o build issues in the sim.
> >>      Looks like the thread lost steam a bit - can we stoke the fire
> >>      again?
> 
> I just committed the dv-sockser.o fix to the 4.6 branch and head.

thanks!  hopefully you'll keep hackin on the sim ;).
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: one week to gdb-7.6 release?

[Ralf Corsepius]

On 03/20/2013 05:00 PM, Joel Brobecker wrote:
>    * dv-sockser.o build issues in the sim.
>      Looks like the thread lost steam a bit
Sorry, I haven't had a chance to revisit this issue. Should there be 
something to test, I could try later this week.

Ralf

Re: one week to gdb-7.6 release?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 329 bytes --]

On Wednesday 20 March 2013 12:00:32 Joel Brobecker wrote:
>   * dv-sockser.o build issues in the sim.
>     Looks like the thread lost steam a bit - can we stoke the fire again?

just to be clear for anyone watching, this should be all set in both the 
branch and cvs head.  i'm not aware of any outstanding issues.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]