one week to gdb-7.6 release?

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
> 

unbreak Windows hosted cross debugger builds (was: Re: one week to gdb-7.6 release?)

[Pedro Alves]

On 04/05/2013 08:21 AM, Eli Zaretskii wrote:

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

OK with me.

I'd have personally preferred a version that adds "get_absolute_argv0" to
both mingw-hdep.c and posix-hdep.c, but we can do that if
we find a need to do more than xstrdup for !Windows...

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

Missing period after "here".

-- 
Pedro Alves

Re: unbreak Windows hosted cross debugger builds gdb-7.6 release?)

[Eli Zaretskii]

> Date: Fri, 05 Apr 2013 20:33:30 +0100
> From: Pedro Alves <palves@redhat.com>
> CC: brobecker@adacore.com, gdb-patches@sourceware.org,
>         jan.kratochvil@redhat.com
> 
> On 04/05/2013 08:21 AM, Eli Zaretskii wrote:
> 
> >> OK to commit, including the branch (which will get a different change,
> >> since there's no need to remove the previous commit there)?
> 
> OK with me.

Thanks, committed to both mainline and the 7.6 branch.

> I'd have personally preferred a version that adds "get_absolute_argv0" to
> both mingw-hdep.c and posix-hdep.c, but we can do that if
> we find a need to do more than xstrdup for !Windows...

Exactly my line of reasoning.

> >> 	* main.h (windows_get_absolute_argv0): ...to here
> 
> Missing period after "here".

Fixed.

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

m32r sim was Re: one week to gdb-7.6 release?

[Joel Sherrill]

[-- Attachment #1: Type: text/plain, Size: 1974 bytes --]


On 3/29/2013 1:54 AM, Ralf Corsepius wrote:
> 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).
And Mike's.
> 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?
Looking back at 7.5.91, I see that m32r unconditionally uses 
dv-sockser.o and
I don't know how it built before.

The references to dv-sockser.o methods appear to be properly conditionalized
in the code.  So it is the Makefile.in and our interpretation that the 
simulated
hardware should be "always on" versus "yes enabled" by default.

Attached is an untested patch.



> Ralf
>


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


[-- Attachment #2: 0001-m32r-dv-sockser.o-is-not-always-used.patch --]
[-- Type: text/plain, Size: 3416 bytes --]

From b703563c73248c12f4832d85506d7a7b3574d58f Mon Sep 17 00:00:00 2001
From: Joel Sherrill <joel.sherrill@oarcorp.com>
Date: Fri, 29 Mar 2013 09:43:32 -0500
Subject: [PATCH] m32r: dv-sockser.o is not always used

2013-03-29  Joel Sherrill  <joel.sherrill@oarcorp.com>

	* configure.ac: Add m32r_extra_objs. Change simulator hardware
	from always on to defaulting to yes it is enabled.
	* Makefile.in: Conditionalize reference to dv-sockser.o.
	* configure: Regenerated.
---
 sim/m32r/Makefile.in  |    5 +----
 sim/m32r/configure    |   16 ++++++----------
 sim/m32r/configure.ac |   11 +++--------
 3 files changed, 10 insertions(+), 22 deletions(-)

diff --git a/sim/m32r/Makefile.in b/sim/m32r/Makefile.in
index 89f1063..095ac9a 100644
--- a/sim/m32r/Makefile.in
+++ b/sim/m32r/Makefile.in
@@ -24,9 +24,6 @@ M32RX_OBJS = m32rx.o cpux.o decodex.o modelx.o mloopx.o
 M32R2_OBJS = m32r2.o cpu2.o decode2.o model2.o mloop2.o
 TRAPS_OBJ = @traps_obj@
 
-CONFIG_DEVICES = dv-sockser.o
-CONFIG_DEVICES =
-
 SIM_OBJS = \
 	$(SIM_NEW_COMMON_OBJS) \
 	sim-cpu.o \
@@ -42,7 +39,7 @@ SIM_OBJS = \
 	$(M32R2_OBJS) \
 	$(TRAPS_OBJ) \
 	devices.o \
-	$(CONFIG_DEVICES)
+	$(m32r_extra_objs)
 
 # Extra headers included by sim-main.h.
 SIM_EXTRA_DEPS = \
diff --git a/sim/m32r/configure b/sim/m32r/configure
index 376acfb..7f0c05a 100755
--- a/sim/m32r/configure
+++ b/sim/m32r/configure
@@ -601,6 +601,7 @@ ac_includes_default="\
 ac_subst_vars='LTLIBOBJS
 LIBOBJS
 cgen_breaks
+m32r_extra_objs
 SIM_DV_SOCKSER_O
 sim_extra_cflags
 traps_obj
@@ -12279,7 +12280,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 12282 "configure"
+#line 12283 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -12385,7 +12386,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 12388 "configure"
+#line 12389 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -13354,7 +13355,7 @@ fi
 
 
 
-if test x"always" != x"no"; then
+if test x"yes" != x"no"; then
   enable_sim_hardware=yes
 else
   enable_sim_hardware=no
@@ -13385,7 +13386,7 @@ case ${enable_sim_hardware} in
 esac
 
 if test "$sim_hw_p" != yes; then
-  if test "always" = "always"; then
+  if test "yes" = "always"; then
     as_fn_error "Sorry, but this simulator requires that hardware support
 be enabled. Please configure without --disable-hw-support." "$LINENO" 5
   fi
@@ -13468,12 +13469,7 @@ fi
   esac
 fi
 
-
-if test -z "$SIM_DV_SOCKSER_O"; then
-	as_fn_error "Sorry, but hardware support in this simulator unconditionally
-relies on dv-sockser.o which is unavailable for your host. Please fix this
-simulator." "$LINENO" 5
-fi
+m32r_extra_objs="$SIM_DV_SOCKSER_O"
 
 
 
diff --git a/sim/m32r/configure.ac b/sim/m32r/configure.ac
index f0422a2..76fed95 100644
--- a/sim/m32r/configure.ac
+++ b/sim/m32r/configure.ac
@@ -27,13 +27,8 @@ SIM_AC_OPTION_CGEN_MAINT
 AC_SUBST(traps_obj)
 AC_SUBST(sim_extra_cflags)
 
-SIM_AC_OPTION_HARDWARE(always,"","")
-
-if test -z "$SIM_DV_SOCKSER_O"; then
-	AC_MSG_ERROR([Sorry, but hardware support in this simulator unconditionally
-relies on dv-sockser.o which is unavailable for your host. Please fix this
-simulator.])
-fi
-
+SIM_AC_OPTION_HARDWARE(yes,"","")
+m32r_extra_objs="$SIM_DV_SOCKSER_O"
+AC_SUBST(m32r_extra_objs)
 
 SIM_AC_OUTPUT
-- 
1.7.1

Re: m32r sim was Re: one week to gdb-7.6 release?

[Mike Frysinger]

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

On Friday 29 March 2013 10:46:22 Joel Sherrill wrote:
> On 3/29/2013 1:54 AM, Ralf Corsepius wrote:
> > 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?
> 
> Looking back at 7.5.91, I see that m32r unconditionally uses
> dv-sockser.o and
> I don't know how it built before.

two reasons:
 - it never defined HAVE_DV_SOCKSER
 - it adds dv-sockser.o in Makefile.in only to then clear the variable
so it had all the framework for the code, but never actually enabled it :).  
your patch actually fixed that part.

> The references to dv-sockser.o methods appear to be properly
> conditionalized in the code.  So it is the Makefile.in and our
> interpretation that the simulated
> hardware should be "always on" versus "yes enabled" by default.
> 
> Attached is an untested patch.

you should also update m32r/tconfig.in and remove the 3 lines related to #if 
0/HAVE_DV_SOCKSER.

also, you'll need to apply the same fix to frv.  it too has proper 
HAVE_DV_SOCKSER conditionals, and explicitly lists it in Makefile.in, only to 
later disable it.
-mike

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

Re: m32r sim was Re: one week to gdb-7.6 release?

[Joel Brobecker]

> > Looking back at 7.5.91, I see that m32r unconditionally uses
> > dv-sockser.o and
> > I don't know how it built before.
[...]
Thank you again, guys, for being of top of it. Let's hope we are
getting to the bottom of things...

I have to admit that the number of iterations and the amount of
research/testing needed in order to try to get this right is
making me slightly nervous. Nothing we can do about it for
this release. But for future releases, Ralf & Joel, do you think
you could incorporate some regular testing of the HEAD on your
end? It would allow us to spot those issues during the development
cycle, and give the fixes more time to mature, rather than putting
them in at the last second...

Thanks!
-- 
Joel

Re: m32r sim was Re: one week to gdb-7.6 release?

[Joel Sherrill]

On 3/29/2013 11:42 AM, Joel Brobecker wrote:
>>> Looking back at 7.5.91, I see that m32r unconditionally uses
>>> dv-sockser.o and
>>> I don't know how it built before.
> [...]
> Thank you again, guys, for being of top of it. Let's hope we are
> getting to the bottom of things...
>
> I have to admit that the number of iterations and the amount of
> research/testing needed in order to try to get this right is
> making me slightly nervous. Nothing we can do about it for
> this release. But for future releases, Ralf & Joel, do you think
> you could incorporate some regular testing of the HEAD on your
> end? It would allow us to spot those issues during the development
> cycle, and give the fixes more time to mature, rather than putting
> them in at the last second...
I have been testing the head fairly regularly but not all of these
combinations and not on mingw.

Do you have some idea of testing requirements?
> 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: m32r sim was Re: one week to gdb-7.6 release?

[Joel Brobecker]

> I have been testing the head fairly regularly but not all of these
> combinations and not on mingw.

That's understandable, and expected IMO. You can only be expected
to test the configurations you are interested in and want to maintain.
The part about MinGW could be covered by Ralf, for instance (assuming
I understand things correctly, since Ralf was the first to report
a regression).

-- 
Joel

Re: m32r sim was Re: one week to gdb-7.6 release?

[Ralf Corsepius]

On 03/29/2013 05:42 PM, Joel Brobecker wrote:
>>> Looking back at 7.5.91, I see that m32r unconditionally uses
>>> dv-sockser.o and
>>> I don't know how it built before.
> [...]
> Thank you again, guys, for being of top of it. Let's hope we are
> getting to the bottom of things...

FYI: My most recent built went without major problems on all platforms. 
There are some minor issues (mostly with mingw32-w64), but I don't see a 
pressing need to address them now.

> I have to admit that the number of iterations and the amount of
> research/testing needed in order to try to get this right is
> making me slightly nervous. Nothing we can do about it for
> this release. But for future releases, Ralf & Joel, do you think
> you could incorporate some regular testing of the HEAD on your
> end?

Well, I am not actually developing on gdb, but am packaging rtems-gdbs 
for different host OSes. Therefore, I am usually jumping-in when gdb 
releases a pre-release tarball and am testing building it. Apologies, 
if this is inconvenient to you,

Ralf

Re: m32r sim was Re: one week to gdb-7.6 release?

[Joel Brobecker]

> >I have to admit that the number of iterations and the amount of
> >research/testing needed in order to try to get this right is
> >making me slightly nervous. Nothing we can do about it for
> >this release. But for future releases, Ralf & Joel, do you think
> >you could incorporate some regular testing of the HEAD on your
> >end?
> 
> Well, I am not actually developing on gdb, but am packaging
> rtems-gdbs for different host OSes. Therefore, I am usually
> jumping-in when gdb releases a pre-release tarball and am testing
> building it. Apologies, if this is inconvenient to you,

It's not inconvenient to me, but it significantly delays the release
cycle to find problems of this sort so late in the game, and it also
reduces the amount of exposure the fix might have. It's such a shame
because such errors are so each to catch right away... All it needs
is a little nightly/weekly script that fetches the latest head, and
rebuilds the configurations that you care about. I am asking whether
you could help with that, since these are the targets that you do
care about.

-- 
Joel

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