bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pushed][PATCH v3 1/4] Extended-remote follow exec


From: Pedro Alves
Subject: Re: [pushed][PATCH v3 1/4] Extended-remote follow exec
Date: Fri, 17 Feb 2017 16:45:01 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]