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

[John Baldwin <jhb@FreeBSD.org>]

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