[pushed,v3,1/4] Extended-remote follow exec

Message ID 87vauuiqkj.fsf@euler.schwinge.homeip.net
State New, archived
Headers

Commit Message

Thomas Schwinge Dec. 8, 2016, 11:54 a.m. UTC
  Hi!

On Fri, 11 Sep 2015 11:38:15 -0700, Don Breazeal <donb@codesourcery.com> wrote:
> Here is what I pushed.

> --- a/gdb/remote.c
> +++ b/gdb/remote.c

> @@ -6089,11 +6178,42 @@ Packet: '%s'\n"),
>  	      event->ws.kind = TARGET_WAITKIND_VFORK_DONE;
>  	      p = skip_to_semicolon (p1 + 1);
>  	    }
> +	  else if (strncmp (p, "exec", p1 - p) == 0)
> +	    {
> +	      ULONGEST ignored;
> +	      char pathname[PATH_MAX];
> +	      int pathlen;
> +
> +	      /* Determine the length of the execd pathname.  */
> +	      p = unpack_varlen_hex (++p1, &ignored);
> +	      pathlen = (p - p1) / 2;
> +
> +	      /* Save the pathname for event reporting and for
> +		 the next run command.  */
> +	      hex2bin (p1, (gdb_byte *) pathname, pathlen);
> +	      pathname[pathlen] = '\0';
> +
> +	      /* This is freed during event handling.  */
> +	      event->ws.value.execd_pathname = xstrdup (pathname);
> +	      event->ws.kind = TARGET_WAITKIND_EXECD;
> +
> +	      /* Skip the registers included in this packet, since
> +		 they may be for an architecture different from the
> +		 one used by the original program.  */
> +	      skipregs = 1;
> +	    }

On GNU/Hurd, there is no "#define PATH_MAX", so this fails to build.
(I'm aware that there is other PATH_MAX usage in GDB sources, which we
ought to fix at some point, for example in gdbserver -- which is not yet
enabled for GNU/Hurd.)

OK to push the following?  (Similar to Svante's patch in
<https://bugs.debian.org/834575>.)



Grüße
 Thomas
  

Comments

Pedro Alves Feb. 17, 2017, 4:45 p.m. UTC | #1
Hi Thomas,

Only noticed this patch now.

> On GNU/Hurd, there is no "#define PATH_MAX", so this fails to build.
> (I'm aware that there is other PATH_MAX usage in GDB sources, which we
> ought to fix at some point, for example in gdbserver -- which is not yet
> enabled for GNU/Hurd.)
> 
> OK to push the following?  (Similar to Svante's patch in
> <https://bugs.debian.org/834575>.)


> 
> --- gdb/remote.c
> +++ gdb/remote.c
> @@ -6927,7 +6927,6 @@ Packet: '%s'\n"),
>  	  else if (strprefix (p, p1, "exec"))
>  	    {
>  	      ULONGEST ignored;
> -	      char pathname[PATH_MAX];
>  	      int pathlen;
>  
>  	      /* Determine the length of the execd pathname.  */
> @@ -6936,11 +6935,12 @@ Packet: '%s'\n"),
>  
>  	      /* Save the pathname for event reporting and for
>  		 the next run command.  */
> +	      char *pathname = (char *) xmalloc (pathlen + 1);
>  	      hex2bin (p1, (gdb_byte *) pathname, pathlen);
>  	      pathname[pathlen] = '\0';


hex2bin can throw, so wrap with a cleanup:

              char *pathname = (char *) xmalloc (pathlen + 1);
              struct cleanup *old_chain = make_cleanup (xfree, pathname);
  	      hex2bin (p1, (gdb_byte *) pathname, pathlen);
  	      pathname[pathlen] = '\0';
              discard_cleanups (old_chain);

OK with that change.

Thanks,
Pedro Alves
  

Patch

--- gdb/remote.c
+++ gdb/remote.c
@@ -6927,7 +6927,6 @@  Packet: '%s'\n"),
 	  else if (strprefix (p, p1, "exec"))
 	    {
 	      ULONGEST ignored;
-	      char pathname[PATH_MAX];
 	      int pathlen;
 
 	      /* Determine the length of the execd pathname.  */
@@ -6936,11 +6935,12 @@  Packet: '%s'\n"),
 
 	      /* Save the pathname for event reporting and for
 		 the next run command.  */
+	      char *pathname = (char *) xmalloc (pathlen + 1);
 	      hex2bin (p1, (gdb_byte *) pathname, pathlen);
 	      pathname[pathlen] = '\0';
 
 	      /* This is freed during event handling.  */
-	      event->ws.value.execd_pathname = xstrdup (pathname);
+	      event->ws.value.execd_pathname = pathname;
 	      event->ws.kind = TARGET_WAITKIND_EXECD;
 
 	      /* Skip the registers included in this packet, since