[PATCH] gdb: fix -Wdeprecated-declarations on macOS

[PATCH] gdb: fix -Wdeprecated-declarations on macOS

[Enze Li]

I noticed that there are some issues when compiling on macOS.  There are
a few places where errors like the following are reported,

======
  CXX    cli/cli-cmds.o
cli/cli-cmds.c:929:14: error: 'vfork' is deprecated: Use posix_spawn or fork [-Werror,-Wdeprecated-declarations]
  if ((pid = vfork ()) == 0)
             ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/unistd.h:604:1: note: 'vfork' has been explicitly marked deprecated here
__deprecated_msg("Use posix_spawn or fork")
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:208:48: note: expanded from macro '__deprecated_msg'
        #define __deprecated_msg(_msg) __attribute__((__deprecated__(_msg)))
                                                      ^
1 error generated.
======

This patch is only available for the macOS platform.  This is done by
using macros to differentiate between specific platforms.

Tested by rebuilding both on x86_64 linux and macOS Big Sur.
---
 gdb/cli/cli-cmds.c      | 4 ++++
 gdb/nat/fork-inferior.c | 4 ++++
 gdb/ser-pipe.c          | 4 ++++
 3 files changed, 12 insertions(+)

diff --git a/gdb/cli/cli-cmds.c b/gdb/cli/cli-cmds.c
index 0c680896c917..a1eac4c024f4 100644
--- a/gdb/cli/cli-cmds.c
+++ b/gdb/cli/cli-cmds.c
@@ -926,7 +926,11 @@ run_under_shell (const char *arg, int from_tty)
 #else /* Can fork.  */
   int status, pid;
 
+#ifdef __APPLE__
+  if ((pid = fork ()) == 0)
+#else
   if ((pid = vfork ()) == 0)
+#endif
     {
       const char *p, *user_shell = get_shell ();
 
diff --git a/gdb/nat/fork-inferior.c b/gdb/nat/fork-inferior.c
index 968983b20215..a9324a550011 100644
--- a/gdb/nat/fork-inferior.c
+++ b/gdb/nat/fork-inferior.c
@@ -355,7 +355,11 @@ fork_inferior (const char *exec_file_arg, const std::string &allargs,
     pid = fork ();
   else
 #endif
+#ifndef __APPLE__
     pid = vfork ();
+#else
+    pid = fork();
+#endif
 
   if (pid < 0)
     perror_with_name (("vfork"));
diff --git a/gdb/ser-pipe.c b/gdb/ser-pipe.c
index 47ccd33cece3..2e9bfe0c0ceb 100644
--- a/gdb/ser-pipe.c
+++ b/gdb/ser-pipe.c
@@ -81,7 +81,11 @@ pipe_open (struct serial *scb, const char *name)
      apparent call to vfork() below *might* actually be a call to
      fork() due to the fact that autoconf will ``#define vfork fork''
      on certain platforms.  */
+#ifndef __APPLE__
   pid = vfork ();
+#else
+  pid = fork ();
+#endif
   
   /* Error.  */
   if (pid == -1)
-- 
2.39.1

Re: [PATCH] gdb: fix -Wdeprecated-declarations on macOS

[Simon Marchi]

On 3/28/23 10:16, Enze Li via Gdb-patches wrote:
> I noticed that there are some issues when compiling on macOS.  There are
> a few places where errors like the following are reported,
> 
> ======
>   CXX    cli/cli-cmds.o
> cli/cli-cmds.c:929:14: error: 'vfork' is deprecated: Use posix_spawn or fork [-Werror,-Wdeprecated-declarations]
>   if ((pid = vfork ()) == 0)
>              ^
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/unistd.h:604:1: note: 'vfork' has been explicitly marked deprecated here
> __deprecated_msg("Use posix_spawn or fork")
> ^
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:208:48: note: expanded from macro '__deprecated_msg'
>         #define __deprecated_msg(_msg) __attribute__((__deprecated__(_msg)))
>                                                       ^
> 1 error generated.
> ======
> 
> This patch is only available for the macOS platform.  This is done by
> using macros to differentiate between specific platforms.
> 
> Tested by rebuilding both on x86_64 linux and macOS Big Sur.

Any idea why vfork is deprecated on macOS?  I can't find any answer
online.

I think it would be good to have a gdb_ util function with the ifdef at
a single place, with an appropriate comment.  I don't know how to call
this function though.  Would calling it gdb_vfork be misleading, because
it won't always vfork?

Simon

Re: [PATCH] gdb: fix -Wdeprecated-declarations on macOS

[John Baldwin]

On 3/28/23 7:55 AM, Simon Marchi via Gdb-patches wrote:
> On 3/28/23 10:16, Enze Li via Gdb-patches wrote:
>> I noticed that there are some issues when compiling on macOS.  There are
>> a few places where errors like the following are reported,
>>
>> ======
>>    CXX    cli/cli-cmds.o
>> cli/cli-cmds.c:929:14: error: 'vfork' is deprecated: Use posix_spawn or fork [-Werror,-Wdeprecated-declarations]
>>    if ((pid = vfork ()) == 0)
>>               ^
>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/unistd.h:604:1: note: 'vfork' has been explicitly marked deprecated here
>> __deprecated_msg("Use posix_spawn or fork")
>> ^
>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:208:48: note: expanded from macro '__deprecated_msg'
>>          #define __deprecated_msg(_msg) __attribute__((__deprecated__(_msg)))
>>                                                        ^
>> 1 error generated.
>> ======
>>
>> This patch is only available for the macOS platform.  This is done by
>> using macros to differentiate between specific platforms.
>>
>> Tested by rebuilding both on x86_64 linux and macOS Big Sur.
> 
> Any idea why vfork is deprecated on macOS?  I can't find any answer
> online.
> 
> I think it would be good to have a gdb_ util function with the ifdef at
> a single place, with an appropriate comment.  I don't know how to call
> this function though.  Would calling it gdb_vfork be misleading, because
> it won't always vfork?

Even if vfork is deprecated, you still want to use it instead of fork I think
as long as it exists.  The real fix is to add a patch to use posix_spawn
to fork the shell instead of vfork when posix_spawn exists.  posix_spawn is
just a wrapper around vfork + execve on FreeBSD's libc for example (I haven't
looked to see what it is on Linux but suspect it is similar).

-- 
John Baldwin

Re: [PATCH] gdb: fix -Wdeprecated-declarations on macOS

[Tom Tromey]

>>>>> "John" == John Baldwin <jhb@FreeBSD.org> writes:

John> Even if vfork is deprecated, you still want to use it instead of fork I think
John> as long as it exists.  The real fix is to add a patch to use posix_spawn
John> to fork the shell instead of vfork when posix_spawn exists.  posix_spawn is
John> just a wrapper around vfork + execve on FreeBSD's libc for example (I haven't
John> looked to see what it is on Linux but suspect it is similar).

I'm not sure we can do this in fork-inferior due to the need to
PTRACE_TRACEME in the child.

The other cases could maybe use the PEX stuff from libiberty?

Tom

Re: [PATCH] gdb: fix -Wdeprecated-declarations on macOS

[Simon Marchi]

On 3/28/23 11:10, John Baldwin wrote:
> On 3/28/23 7:55 AM, Simon Marchi via Gdb-patches wrote:
>> On 3/28/23 10:16, Enze Li via Gdb-patches wrote:
>>> I noticed that there are some issues when compiling on macOS.  There are
>>> a few places where errors like the following are reported,
>>>
>>> ======
>>>    CXX    cli/cli-cmds.o
>>> cli/cli-cmds.c:929:14: error: 'vfork' is deprecated: Use posix_spawn or fork [-Werror,-Wdeprecated-declarations]
>>>    if ((pid = vfork ()) == 0)
>>>               ^
>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/unistd.h:604:1: note: 'vfork' has been explicitly marked deprecated here
>>> __deprecated_msg("Use posix_spawn or fork")
>>> ^
>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:208:48: note: expanded from macro '__deprecated_msg'
>>>          #define __deprecated_msg(_msg) __attribute__((__deprecated__(_msg)))
>>>                                                        ^
>>> 1 error generated.
>>> ======
>>>
>>> This patch is only available for the macOS platform.  This is done by
>>> using macros to differentiate between specific platforms.
>>>
>>> Tested by rebuilding both on x86_64 linux and macOS Big Sur.
>>
>> Any idea why vfork is deprecated on macOS?  I can't find any answer
>> online.
>>
>> I think it would be good to have a gdb_ util function with the ifdef at
>> a single place, with an appropriate comment.  I don't know how to call
>> this function though.  Would calling it gdb_vfork be misleading, because
>> it won't always vfork?
> 
> Even if vfork is deprecated, you still want to use it instead of fork I think
> as long as it exists.  The real fix is to add a patch to use posix_spawn
> to fork the shell instead of vfork when posix_spawn exists.  posix_spawn is
> just a wrapper around vfork + execve on FreeBSD's libc for example (I haven't
> looked to see what it is on Linux but suspect it is similar).

I guess that using posix_spawn would require some very significant
architectural changes?  Right now, we fork (or vfork), do some cleanup /
prep work, and then exec.  How do you do that with posix_spawn?

Simon

Re: [PATCH] gdb: fix -Wdeprecated-declarations on macOS

[John Baldwin]

On 3/28/23 9:01 AM, Simon Marchi wrote:
> On 3/28/23 11:10, John Baldwin wrote:
>> On 3/28/23 7:55 AM, Simon Marchi via Gdb-patches wrote:
>>> On 3/28/23 10:16, Enze Li via Gdb-patches wrote:
>>>> I noticed that there are some issues when compiling on macOS.  There are
>>>> a few places where errors like the following are reported,
>>>>
>>>> ======
>>>>     CXX    cli/cli-cmds.o
>>>> cli/cli-cmds.c:929:14: error: 'vfork' is deprecated: Use posix_spawn or fork [-Werror,-Wdeprecated-declarations]
>>>>     if ((pid = vfork ()) == 0)
>>>>                ^
>>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/unistd.h:604:1: note: 'vfork' has been explicitly marked deprecated here
>>>> __deprecated_msg("Use posix_spawn or fork")
>>>> ^
>>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:208:48: note: expanded from macro '__deprecated_msg'
>>>>           #define __deprecated_msg(_msg) __attribute__((__deprecated__(_msg)))
>>>>                                                         ^
>>>> 1 error generated.
>>>> ======
>>>>
>>>> This patch is only available for the macOS platform.  This is done by
>>>> using macros to differentiate between specific platforms.
>>>>
>>>> Tested by rebuilding both on x86_64 linux and macOS Big Sur.
>>>
>>> Any idea why vfork is deprecated on macOS?  I can't find any answer
>>> online.
>>>
>>> I think it would be good to have a gdb_ util function with the ifdef at
>>> a single place, with an appropriate comment.  I don't know how to call
>>> this function though.  Would calling it gdb_vfork be misleading, because
>>> it won't always vfork?
>>
>> Even if vfork is deprecated, you still want to use it instead of fork I think
>> as long as it exists.  The real fix is to add a patch to use posix_spawn
>> to fork the shell instead of vfork when posix_spawn exists.  posix_spawn is
>> just a wrapper around vfork + execve on FreeBSD's libc for example (I haven't
>> looked to see what it is on Linux but suspect it is similar).
> 
> I guess that using posix_spawn would require some very significant
> architectural changes?  Right now, we fork (or vfork), do some cleanup /
> prep work, and then exec.  How do you do that with posix_spawn?

Hummm, it depends on the prep work.  If you are shuffling things like
fd's you do that as actions you pass to posix_spawn.  However, Tom's
point about PTRACE_ME is true that I don't know if any systems have
a posix_spawn extension to do that operation.  In theory it wouldn't
be hard to add such a thing to posix_spawn, but it's not there today.
If MacOS does support attaching the debugger for its posix_spawn it
might still be better to use posix_spawn on MacOS, but if not I guess
we are stuck with plain fork.

-- 
John Baldwin

Re: [PATCH] gdb: fix -Wdeprecated-declarations on macOS

[John Baldwin]

On 3/28/23 10:52 AM, John Baldwin wrote:
> On 3/28/23 9:01 AM, Simon Marchi wrote:
>> On 3/28/23 11:10, John Baldwin wrote:
>>> On 3/28/23 7:55 AM, Simon Marchi via Gdb-patches wrote:
>>>> On 3/28/23 10:16, Enze Li via Gdb-patches wrote:
>>>>> I noticed that there are some issues when compiling on macOS.  There are
>>>>> a few places where errors like the following are reported,
>>>>>
>>>>> ======
>>>>>      CXX    cli/cli-cmds.o
>>>>> cli/cli-cmds.c:929:14: error: 'vfork' is deprecated: Use posix_spawn or fork [-Werror,-Wdeprecated-declarations]
>>>>>      if ((pid = vfork ()) == 0)
>>>>>                 ^
>>>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/unistd.h:604:1: note: 'vfork' has been explicitly marked deprecated here
>>>>> __deprecated_msg("Use posix_spawn or fork")
>>>>> ^
>>>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:208:48: note: expanded from macro '__deprecated_msg'
>>>>>            #define __deprecated_msg(_msg) __attribute__((__deprecated__(_msg)))
>>>>>                                                          ^
>>>>> 1 error generated.
>>>>> ======
>>>>>
>>>>> This patch is only available for the macOS platform.  This is done by
>>>>> using macros to differentiate between specific platforms.
>>>>>
>>>>> Tested by rebuilding both on x86_64 linux and macOS Big Sur.
>>>>
>>>> Any idea why vfork is deprecated on macOS?  I can't find any answer
>>>> online.
>>>>
>>>> I think it would be good to have a gdb_ util function with the ifdef at
>>>> a single place, with an appropriate comment.  I don't know how to call
>>>> this function though.  Would calling it gdb_vfork be misleading, because
>>>> it won't always vfork?
>>>
>>> Even if vfork is deprecated, you still want to use it instead of fork I think
>>> as long as it exists.  The real fix is to add a patch to use posix_spawn
>>> to fork the shell instead of vfork when posix_spawn exists.  posix_spawn is
>>> just a wrapper around vfork + execve on FreeBSD's libc for example (I haven't
>>> looked to see what it is on Linux but suspect it is similar).
>>
>> I guess that using posix_spawn would require some very significant
>> architectural changes?  Right now, we fork (or vfork), do some cleanup /
>> prep work, and then exec.  How do you do that with posix_spawn?
> 
> Hummm, it depends on the prep work.  If you are shuffling things like
> fd's you do that as actions you pass to posix_spawn.  However, Tom's
> point about PTRACE_ME is true that I don't know if any systems have
> a posix_spawn extension to do that operation.  In theory it wouldn't
> be hard to add such a thing to posix_spawn, but it's not there today.
> If MacOS does support attaching the debugger for its posix_spawn it
> might still be better to use posix_spawn on MacOS, but if not I guess
> we are stuck with plain fork.

Ah, MacOS does support such an extension via an OS-specific flag passed
to posix_spawnattr_setflags:

      POSIX_SPAWN_START_SUSPENDED  Apple Extension: If this bit is set, then
                                   the child process will be created as if it
                                   immediately received a SIGSTOP signal, per-
                                   mitting debuggers, profilers, and other pro-
                                   grams to manipulate the process before it
                                   begins execution in user space.  This per-
                                   mits, for example, obtaining exact instruc-
                                   tion counts, or debugging very early in
                                   dyld(1).  To resume the child process, it
                                   must be sent a SIGCONT signal.

-- 
John Baldwin