Don't search for $SHELL in procfs.c

[Pedro Alves]

On 06/08/2018 01:12 PM, Rainer Orth wrote:
> When building gdb mainline on Solaris with g++ 8.1 with the fixes in
> 
> 	https://sourceware.org/ml/gdb-patches/2018-06/msg00196.html
> 
> one failure remains:
> 
> /vol/src/gnu/gdb/gdb/dist/gdb/procfs.c: In member function ‘virtual void procfs_target::create_inferior(const char*, const string&, char**, int)’:
> /vol/src/gnu/gdb/gdb/dist/gdb/procfs.c:3098:12: error: ‘char* std::strncpy(char*, const char*, size_t)’ output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
>     strncpy (tryname, p, len);
>     ~~~~~~~~^~~~~~~~~~~~~~~~~
> /vol/src/gnu/gdb/gdb/dist/gdb/procfs.c:3097:19: note: length computed here
>       len = strlen (p);
>             ~~~~~~~^~~
> cc1plus: all warnings being treated as errors
> 
> I didn't even try to get rid of this, but revived an older patch of mine
> to rip out the code to search for $SHELL in $PATH.  procfs.c is the only
> caller of fork_inferior that does this, and I don't see why Solaris
> should be special here.  Since all callers call fork_inferior with
> shell_file_arg = NULL now, one might even think about getting rid of
> that arg as a followup.

On Unix ports, spawning a child process results in one fork, tracing the
fork child, and then one exec event for when the child execs the shell,
and then another exec event when the shell execs the program that we want
the child to be running.

The comment is talking about some system behaving differently:

-      /* We will be looking down the PATH to find shell_file.  If we
-	 just do this the normal way (via execlp, which operates by
-	 attempting an exec for each element of the PATH until it
-	 finds one which succeeds), then there will be an exec for
-	 each failed attempt, each of which will cause a PR_SYSEXIT
-	 stop, and we won't know how to distinguish the PR_SYSEXIT's
-	 for these failed execs with the ones for successful execs
-	 (whether the exec has succeeded is stored at that time in the
-	 carry bit or some such architecture-specific and
-	 non-ABI-specified place).
-

That might have been for some older Solaris, or even for one of the
other ports that used to use procfs.c too (IRIX, etc.).

If it's not relevant for Solaris versions we care about, yeah,
let's just get rid of it.

> 
> Built on 64-bit Solaris 11.5/x86 (amd64-pc-solaris2.11), make check
> running.  Ok for mainline if that passes?

OK.

Thanks,
Pedro Alves