Message ID | OS3P286MB2152EBC805B1484BE3970863F0889@OS3P286MB2152.JPNP286.PROD.OUTLOOK.COM |
---|---|
State | New |
Headers |
Return-Path: <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A5720385842B for <patchwork@sourceware.org>; Tue, 28 Mar 2023 14:16:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A5720385842B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1680013009; bh=qUoA4o/2BKkD8+nxgqwlmj8qtNMYcIIyKUFu1YyE6B8=; h=To:Cc:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=R7CBx4GrkdbHnKEt6mSN6lj82VXBX5PD5N+GhixPYmMjrVhw5/JE6EipQdAS1M/kN QIROs1tFxFcGjvv4SaO8IXCQjxRnDGabhFtMkDDVFmWvtWFO+S846YZQcFSQMlD9kz ubDl1+z2TmM9g33spq3t+PK1BHQLkVjPMqkzCMj0= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from JPN01-TYC-obe.outbound.protection.outlook.com (mail-tycjpn01olkn2054.outbound.protection.outlook.com [40.92.99.54]) by sourceware.org (Postfix) with ESMTPS id 329803858C50 for <gdb-patches@sourceware.org>; Tue, 28 Mar 2023 14:16:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 329803858C50 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W2F+94l1Tx5NBR310HCihHfh1EMTuOqCfTZlm9+ecUcdTbysvUFZa5Uj3gg3seZd0FmBvBM0x5eKY8XUR0DgLANBP0g14fxMkIC0JZVzeKEd576QLnJ3r8X48Zk1lU+c5nLBknHv0ls08N4/yMlLjngKF5OHhcaIfz+Wuwnxbzr5pGmG9HFwvP883Bf5KnQI692mfWFPtnTl7NY/i0wqffmNrBPit/7JFGKVKh1OT8leLeCpKWDKShREAVnFqZUTk3IqtUSXyrfwSul0dhRS04Op82+xpg6tMDK2PQRtExFAEF1EIB+pejIf+S37bOt3awuWii/bvKIqnmhILbaf9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qUoA4o/2BKkD8+nxgqwlmj8qtNMYcIIyKUFu1YyE6B8=; b=QJGidMZh6H+fYTttg4yvvG1pcv61xLJ4MxHe7uTC0XGX721qhhtXeIsLj8bhuO5Nu5Yoc4c5IwNpljYTJg3auQeKzlE88E8HjTeFA/wU8CcXGpORfYR+bJ82Xzm2PXRZla7FLqzwVYoiYGaGnsBYm4AVTKRILMly+VhaPCSJCGjA21P3pe4JrVUoJOKKIST5t/uW/CpF23osT2RYzf2uHQFdKzxw12FEhIeqKkdOnVcdDOgPIXuT9DnnE+ZWFvGGx+AmcK+Q3ICbaYmimbdmZCtBlP7OfHwRfWzMpIOr3Tqw6VSMBAvbGBqHis8UBU+j2DVqSyUhsCM3EPgCz5HCxA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from OS3P286MB2152.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:197::9) by TYCP286MB2718.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:245::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6222.33; Tue, 28 Mar 2023 14:16:20 +0000 Received: from OS3P286MB2152.JPNP286.PROD.OUTLOOK.COM ([fe80::1594:e1c9:6288:453c]) by OS3P286MB2152.JPNP286.PROD.OUTLOOK.COM ([fe80::1594:e1c9:6288:453c%5]) with mapi id 15.20.6222.033; Tue, 28 Mar 2023 14:16:20 +0000 To: gdb-patches@sourceware.org Cc: enze.li@gmx.com Subject: [PATCH] gdb: fix -Wdeprecated-declarations on macOS Date: Tue, 28 Mar 2023 22:16:06 +0800 Message-ID: <OS3P286MB2152EBC805B1484BE3970863F0889@OS3P286MB2152.JPNP286.PROD.OUTLOOK.COM> X-Mailer: git-send-email 2.40.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-TMN: [6J6Ud9tSGrR0CrBDwAPHYnDcUd+dcOBo] X-ClientProxiedBy: SG2PR06CA0195.apcprd06.prod.outlook.com (2603:1096:4:1::27) To OS3P286MB2152.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:197::9) X-Microsoft-Original-Message-ID: <20230328141606.916-1-enze.li@hotmail.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: OS3P286MB2152:EE_|TYCP286MB2718:EE_ X-MS-Office365-Filtering-Correlation-Id: d8494971-80ba-4c6c-1c16-08db2f9700bb X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: F3MH8SBPUtIT2y3NG8NTbrP5z3IH3H7yoXwb4HRXYbn/oa4hxy+3/3dkbIG7Quqi4ARlMfuQFNow/ZZk3IUXxLyu64jvFh5rtVZgcuXUpmeHu9nv6M6x80T9pzNcul0zoWEVbN0qENbBmEcM63YcLbldDDNfC5utCqmsOF1klauLjvOw66Wr0gvOfHvalAJpavUZLn3uZs7nJu/fw75hP0/T5/GGIazPrpAiIQ7EcsvhvilNR8TZi984Hql2IYOOBmL/iQ4kECJdz/E3oLQ4f3lz3zVqpJ+jHH0Z8D3GtMI76U0jXcP7uiw/Vny4gCELchQO2pFwBP6cbFm0X92EX7k3q4zkB8YGVCFov1OepopvI4fFs6t49ZMsVrMAhuC5aWji6QPAy30FBg2Pm9havhT9btYOT+mRHPcNUd/4T5YTQU88TuxszI0CWKheqidk14wb0Ze74aR995dn6AxPB7QJf7tpMA240UllA9uFlMupzriFAfrlvxUmv3raInirlnBIsGbrRB5lSPfD+MDhzJkcJCMxu7ajikCcIVeuil7UjLfHOGWRHX6N8lXOMFQd X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 2TD0F08Nopmov0LjxYmkIie4J1Tk6tdcwXuUYzagzOpY2ku8s1v3HH0t1FisNMfyBOXBEJZafWhzjCH0UASQ/NbwK87h3EHvdZUTeQbvEwGKw1KSDnr8SBdTqphZWco4uvpnW/ds7d1x8TeWse0rICubTONFSiWWVhwRX4aLLUKB7eOcGrJpHN39IRi2MEYg3bX1wu1qXSdWPCdu515MlorLB7UI6YiSysAlbbu4XVq1Pn6q+5MkxhOZ8r9nN9fGZmgvZF1ZoCMpUEjJ/f92RIVI0tBtGPEJIkrkqiDuNm9/6APufMxfD092oXHLoSc6Sf7DuHvqVTQK7bkQLc5b3p2kZUrLpGqOxfDR1FcD11VILXIRku7KgseMSPt1az3gs/F0mzDXuDFqZfrR7hNS3POD+FVpoukd8zx6OcHR2ix+Wb7g62O0EPVVq30Q2wyha1uYEkNzW7dpOIhzyDn6331gEXNKQH0SSEDW32SLapZCY47p0wZnP70UAWybEy24WQXx25ec8xbagM3aFktOLlTyWVR8VVFc08US0lePXyQ62sS62qKtnCs6/qVDpzk8b1sRaK0iN+GEViAyev9MvCLXukPypBVb3mFR+iPhmTWRy+XU1OW2/zxhi4ISl2YMkN1FonkwMZNPKkPeegG9mgg7mO5PkUCYdaSvCx4OjXQmkmELxscNt7ksOnMUvsRp0mEkXKfYknAv6iJ3f37H30pQtD73TqJ+gJ88tcEFQJwHP/Z6jb2mr7kl5hjTt/wgQimPlf0tGJXYmeswaUNlJORLSOEbHoZzaYQwY5V/4cI0CY7S25rkkKb4UL+rkjNnyDDXPtVwUAppbXcyOdkJb4wXNG5fy2On30DdBUMEpqyka3jdiht9ULfa+/kofv/Ai81tQHc7r0/3SVhwrA2TEh0oujTrm5r/6FXLzhwqHhoCTSesAF+QnJuwwY8zET3FKiqgqyEV+A881x9SMyLHvYLzcrZ8UOs9EQ+KWLd5ov+obs/i7CWRMqMhWL4U3AToY+UZLtSNnWZQzuKyHjCZNFzlOKp0s3x6OeCtwMnB4M14W0N5xeqV7hkd7oVu/xGmtYQWjcsWuTXaZUTz7DMcQzYWLHYIfQbBmowuT+fjyCTW9iwBto36TXfAM8AeZTbLq9J2AjDUAnnhlZLjWh4FLgBAhJ0n2zRP1Bj7QlPU//AXTrcflc5I0S1Si2IDEdHt3tuDKQ3E5nUbVGh2kYPEag== X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-05f45.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: d8494971-80ba-4c6c-1c16-08db2f9700bb X-MS-Exchange-CrossTenant-AuthSource: OS3P286MB2152.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2023 14:16:20.5021 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYCP286MB2718 X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list <gdb-patches.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=subscribe> From: Enze Li via Gdb-patches <gdb-patches@sourceware.org> Reply-To: Enze Li <enze.li@hotmail.com> Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
gdb: fix -Wdeprecated-declarations on macOS
|
|
Commit Message
Enze Li
March 28, 2023, 2:16 p.m. UTC
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(+)
Comments
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
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" == 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
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
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.
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.
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)