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

[John Baldwin <jhb@FreeBSD.org>]

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