From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 8EnjGVhncWd3tDgAWB0awg (envelope-from ) for ; Sun, 29 Dec 2024 10:14:32 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=yahoo.de header.i=@yahoo.de header.a=rsa-sha256 header.s=s2048 header.b=IZTjEGbM; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 66AC21E097; Sun, 29 Dec 2024 10:14:32 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=unavailable autolearn_force=no version=4.0.0 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id BBB2F1E05C for ; Sun, 29 Dec 2024 10:14:31 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 67F7C3858C32 for ; Sun, 29 Dec 2024 15:14:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 67F7C3858C32 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=yahoo.de header.i=@yahoo.de header.a=rsa-sha256 header.s=s2048 header.b=IZTjEGbM Received: from sonic308-18.consmr.mail.ir2.yahoo.com (sonic308-18.consmr.mail.ir2.yahoo.com [77.238.178.146]) by sourceware.org (Postfix) with ESMTPS id 8D9EF3858D34 for ; Sun, 29 Dec 2024 15:13:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8D9EF3858D34 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=yahoo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=yahoo.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8D9EF3858D34 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=77.238.178.146 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1735485239; cv=none; b=NCCxIZ3fbzJzXkQKOTMnMnb3kHGEWAq3Pbp2a1+N409ZciAdvDtmWodjIaCrYAeIgNJSCSYM0SMR23TQSoE09mMuZVj5Kws975Y+W/C0GwlMTg2SQ5XYiDD83TyZnMxl2qPGqm6fUhVL0CTNoAeOHGxB56LJmb35WvDIxbqdIEk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1735485239; c=relaxed/simple; bh=K4FgAcjGqs+JjilT8n69xh5xyIxvdnRIrtWGmPwWX+I=; h=DKIM-Signature:Date:From:To:Message-ID:Subject:MIME-Version; b=bjInM/fISD0Hy+j6GnBH7IcJMeGs6hk1TOUIJmoZGUyHas/iieb8j4/2jzt85yRE6l3yj9JSEd1K+DtBR4JKN/O+9ayJbM7zYeExEfmiQOVHt6yISLBfbs27d4SPLQRdJ8BWoV77gZr8TKc6zar8jRopomRUqIDtMRWzmA4eoPM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8D9EF3858D34 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s2048; t=1735485237; bh=K4FgAcjGqs+JjilT8n69xh5xyIxvdnRIrtWGmPwWX+I=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=IZTjEGbM07+F0Wdf/S0KbMEkbthYOsdMnQorkXrDi/L1vboznzKoA4vZm6ktH+6LeloNxtb/ctwCh//0QpAa2yuL/yBgfiVjw484QqHO5CztQv7DKcKU/PJa3A5krnWNnrrvKqZXZUmf5xwisdR4c+jbilmhG6tvXqTnMiLCm4o1KkO+3bHzycQzUMVm/TofgR4DfHNJR+kDYRcwIXuAjdYQrconbtvhl+RWg9gd7ilrdEIIno7hUFR5t3JWOxWwUAjGb35i38JHuaAd3fy7ez/Bm6CEM8fQafyibphNX8JR+1stnc2vuqseZnFagk0804pRThZOvv3Ies1HyRldBQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1735485237; bh=8OboRSDzV9a2BQtj84TZ+dRyuGL3liksNB1jWJFN+t2=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=HDJDgO58LXnN9EcODwAcYB8iqatDO/jyFS1w1VCk/oO3MR3qfCr0SH7Ay15Q3H3fOSIVKWAJgWkgGlNQmyq0ODgwCScoBjtcUlJmYPGBRI6+hYONJndkCxAaJtrQWcoZL1NFdcVtfDNnUu7AzYtLZoGKcYvmHm9lUDmnqx7Q64aZ3aTHhy1XmA8ALO80GU8g8ZMcOjMIGtqotFqgoxNbd/L4Nku1JhAjNDCbzkwPFZ2wRVzlm+GXBnjtVO6hgdxHC5QgVfFdnw6GTcnrLApqvmNyytyc/M8PcLcK9mJystDZd7gl6VKtYmJOUv7NoftGtkzw/+TwSYTO8haGiuDLkw== X-YMail-OSG: osnHZAIVM1kdPsIaz.aHraLoZg9DmpLyhtwjh3n7lWd8QkEMzQmSDE._yo7XjQR Id9vy4aWJv28F4OzOR9QLgpzWAfZjgUTaxW8SLjYQGusSqoWyn9l9snyrMnemQ503Q9KJwj8xN69 0XIS_cXdjoRFt1o.aDemGrSKwwt25tkJjVT1hEPAuw.6o7lijE5iQxjg1b6SgTenQAqIDS2UXIeW ZhD7NJNXwRuwGhiq0TOVUpJaSJwpmq_olxNV5oFqDsP9H5piFybEbKf.vj4iv_O3kjimzwI_wl_I o1FD89Gn5KdfluWcH8yl2rak4oG2M4RIlx6vtbgroqvxB7lez4.CtoCDIB8VeTQPGak2fs2qilCm 5BdPiSmFy_l8SV07ddrdarwuJ5MmetxKF6IjxDzwjmdSm2TPykCLpXbSZSLiLAnAoDDQKsNYXz7q NOxtPvYfrDKKvOHGfqwcRCrXDNG4SqNDwZrBXai0YN3L92GwWgbSqwU7eFBlJSKAbjknZiYXYn9g 0KPtu2Gu.IwPoH4r.TUaPA0WZ8FRvsb6uQoozE.LeZkI99PH31MaNpJW_ZeMkixIfGBQ08iQT6UF HjIcUPULW8bqxt2IXQrMrXjnEf0.MoCDkqqMw59dnB_ljVf2Rchq5QaBCv52pC4Uppj4zQ0XXEBu H_agZqalClzXCkCYPxEfJKlysveLYAoNiLW.DxzhOvQlsCncojuSIiAF4Lr3UuYwBC2Ozboc_.Kc T1D6y_VYC9zqMDKxUMriJZ82qSTVqTdUBZBHUudql9ldruWD9MNQMuHRqdGUuT3n1t.Rb8BIN_E1 _Mo8LrcHuZzOgXJ2PPu8cZyUG7gi8pMSVsa0nu810mvhqXD0cHCPO3LFWEuwhxYnbcKsJ92Pq2_x 1lrHc.jC22qsJfSYPPX3ZNnK6Xy1xK10KaHzTAlSGg9x9JpxA9TNvZKJBsr8jBbtE.fUoEGtXopt .WDvtnhU0mTelNpmKXRM3kAtBPyEjkWEGR9Fq8H6QiabvjlAW_yzygwDqDnTE8Avm4dJ5Bj7UDiu NgfjVqbL8.jZDBb.WY1RRuM4rg65WyghpcMchOC8OoLUlvigyCnOy0kCUMVyA9NEqk_vXlYhRxHu mgzi3EvPmPGP2gmR20qPdKDBRifCW2ndwsZG2sKnNYizpRwEli8kbTxqc.OIhV5QLydQl_7HfEeH Zt3s6TvY2wo8bgK6q.mV1oqNk6P911_gVuksh_L0DmEdodzmoMDTgpl2JDurg4xEYc5DnX4fRSrg EkDLqdcb.GuX6cnTf5rnELAKHU.UAwk.U.Ed4Ex_DzB.7W2hciVvIvpIqH.4HjRpc7sVq91qtVHX k7dnP01_gIICdV5cmB6hBwKdOIh94QdAv9mpDQjRQX.rsc6Ef7WmPCF9wIsW0ACqK8OPd2CboRGl d2lPuUyZq.33cetfdHJwp.bU9hbTdXSYf6Pyzlku64M2y6yTtXeSJW98YHHKxHR2Unq7X4d7LQUO yhanPte79w2OcCFiFIY2wnAI4M03VcTFSBiXsjd7hwc5F5Cyg3VgzU7eKcSCtunribfAwbuh5npk pi2aEau4KIjR7QV8wkjVkjsveECrlrR33rQVwaRobn7QUIAw1A33imodlf0VBSWBMJM1Noa_fU52 WNh8HA_02LvQqXYRfm7kET1dfgqBdsdR_MZh1dOdhKzIV2SNKo4t67JLqcEoS1yyKZ4xz_ft_ND_ iAgHfwasob380CBiWkL1r68uqnLSpOwFDYdYjGC2YtvO5eWbvAa3tQ4ocj8VEdNC.14fLl7kzdoA PYEjWuAoxgN7nBVbYvTp0rQ10wJrW6lr9140VkJ9S9fbUnpPiLuQve67abkhocZ8CPfqKaLuPnRJ gaoqCFA5OU1CNAF89jBqMasq_vff3bKOuFfdY4iyfvvA5QLDaS1yhsWaXjhmWUBHPmiQrHlUsara z4R_KEFvVq1yV6_yDik1yAAshw0TVyByPlZqaBjSaCcVzujNQh0UHMpr2ID2X3gNWD4AmeGCdX37 ZPPV6qanLMN7APOW_FvpcTCVcKVml3rABC1kmz4DSGWhXHK_Bu8NAZwFe73zaLcrGYMAHHOKnQOw UZ8iYyFEaoNYAIJxhobHRaUYworLf5MVA0TH6I.E9jirmgdJgZvbbuDeG8HION9FOVveF5c9qcTm CLnB7BnnFWMn1L9JiXQyUgg-- X-Sonic-MF: X-Sonic-ID: d217420d-0931-47b1-9b9c-915f1574a12d Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ir2.yahoo.com with HTTP; Sun, 29 Dec 2024 15:13:57 +0000 Date: Sun, 29 Dec 2024 15:11:40 +0000 (UTC) From: Hannes Domani To: Joel Brobecker , Eli Zaretskii Cc: "gdb-patches@sourceware.org" Message-ID: <745538212.4148266.1735485100440@mail.yahoo.com> In-Reply-To: <868qryr6nn.fsf@gnu.org> References: <20241229033130.D7F7F803EA@takamaka.gnat.com> <868qryr6nn.fsf@gnu.org> Subject: Re: GDB 16.0.90 available for testing MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.23113 YMailNorrin X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Am Sonntag, 29. Dezember 2024 um 13:55:25 MEZ hat Eli Zaretskii Folgendes geschrieben: > > From: Joel Brobecker > > Date: Sun, 29 Dec 2024 07:31:30 +0400 (+04) > > > > I have just finished creating the gdb-16.0.90 pre-release. > > It is available for download at the following location: > > > >=C2=A0=C2=A0=C2=A0 https://sourceware.org/pub/gdb/snapshots/branch/gdb-1= 6.0.90.tar.xz > > > > A gzip'ed version is also available: gdb-16.0.90.tar.gz. > > > > Please give it a test if you can and report any problems you might find= . > > I've built this pretest with mingw.org's MinGW (GCC 9.2.0), as 32-bit > GDB executable for native Windows debugging, and found the following > > problems: > > > 1. A compilation error in readline/input.c, due to lack of 'alarm' > function.=C2=A0 I have reported that several months ago to the upstream > Readline developers, but the solution they installed only works for > MinGW64.=C2=A0 For mingw.org we need the following patch: > > --- readline/readline/input.c~0=C2=A0=C2=A0=C2=A0 2024-12-29 04:50:07.000= 000000 +0200 > +++ readline/readline/input.c=C2=A0=C2=A0=C2=A0 2024-12-29 12:32:04.19663= 0800 +0200 > @@ -151,6 +151,14 @@ win32_isatty (int fd) > #=C2=A0 define RL_TIMEOUT_USE_SELECT > #else > #=C2=A0 define RL_TIMEOUT_USE_SIGALRM > +#=C2=A0 ifdef __MINGW32_MAJOR_VERSION > +/* mingw.org's MinGW doesn't have 'alarm'.=C2=A0 */ > +unsigned int > +alarm (unsigned int seconds) > +{ > +=C2=A0 return 0; > +} > +#=C2=A0 endif > #endif > > int rl_set_timeout (unsigned int, unsigned int); I wonder why readline doesn't disable the whole stuff where alarm is used on windows, since it doesn't work there anyways. > 2. Compilation error in event-top.c: > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CXX=C2=A0=C2=A0=C2=A0 event-top.o >=C2=A0=C2=A0=C2=A0=C2=A0 In file included from d:\usr\include\winsock2.h:6= 9, >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 from ./../gdbsupport/gdb_select.h:30, >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 from event-top.c:43: >=C2=A0=C2=A0=C2=A0=C2=A0 event-top.c: In function 'fd_set* fd_copy(fd_set*= , const fd_set*, int)': >=C2=A0=C2=A0=C2=A0=C2=A0 event-top.c:1279:22: error: invalid conversion fr= om 'const fd_set*' to 'fd_set*' [-fpermissive] >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1279 |=C2=A0=C2=A0=C2=A0 if (FD_ISSET= (i, src)) >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 ^ >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 | >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 const fd_set* >=C2=A0=C2=A0=C2=A0=C2=A0 d:\usr\include\winsock.h:164:50: note:=C2=A0 init= ializing argument 2 of 'int __FD_ISSET(SOCKET, fd_set*)' >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 164 | __CRT_ALIAS int __FD_ISSET( SOC= KET __fd, fd_set *__set ) >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ~~~~~~~~^~~~~ > > I solved it with an explicit cast, like this: > > --- gdb/event-top.c~0=C2=A0=C2=A0=C2=A0 2024-12-29 04:50:07.000000000 +02= 00 > +++ gdb/event-top.c=C2=A0=C2=A0=C2=A0 2024-12-29 12:33:48.356713700 +0200 > @@ -1276,7 +1276,7 @@ fd_copy (fd_set *dst, const fd_set *src, > { >=C2=A0=C2=A0 FD_ZERO (dst); >=C2=A0=C2=A0 for (int i =3D 0; i < n; ++i) > -=C2=A0=C2=A0=C2=A0 if (FD_ISSET (i, src)) > +=C2=A0=C2=A0=C2=A0 if (FD_ISSET (i, (fd_set *)src)) >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FD_SET (i, dst); > >=C2=A0=C2=A0 return dst; > > But I don't know if this will produce problems for other > implementations of FD_ISSET. > > 3. Running GDB on itself produces the following error message: > >=C2=A0=C2=A0 warning: BFD: error: d:\gnu\gdb-16.0.90\gdb\gdb.exe(.debug_ma= cro) is too large (0x9f585e077fdeba bytes) >=C2=A0=C2=A0 warning: Can't read data for section '.debug_macro' in file '= d:\gnu\gdb-16.0.90\gdb\gdb.exe' >=C2=A0=C2=A0 During symbol reading: missing .debug_macro section > > The size of the section is obviously bogus; the real size is 0x77fdeba > bytes, which is more than 128 MBytes, and so fails malloc.=C2=A0 I tracke= d > the bogus print value to this code in bfd: > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* PR 20801: = Provide a more helpful error message.=C2=A0 */ >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (bfd_get_e= rror () =3D=3D bfd_error_no_memory) >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _bfd_error_handler >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* xgettext:c= -format */ >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (_("error: %p= B(%pA) is too large (%#" PRIx64 " bytes)"), >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 abfd, sec, (u= int64_t) allocsz); > > It sounds like uint64_t values are not printed correctly by BFD in > this 32-bit build?=C2=A0 I ended up using the following kludge: > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (sizeof (a= llocsz ) > sizeof (int)) >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _= bfd_error_handler >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /= * xgettext:c-format */ >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 (_("error: %pB(%pA) is too large (%#" PRIx64 " bytes)"), >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 abfd, sec, (uint64_t) allocsz); >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 else >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _= bfd_error_handler >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /= * xgettext:c-format */ >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 (_("error: %pB(%pA) is too large (%#" PRIx32 " bytes)"), >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 abfd, sec, allocsz); Doesn't the (uint64_t) cast already make sure the allocsz value matches PRIx64, so why does it not work here? What does PRIx64 expand to for you, "llx" or "I64x"? _bfd_print can only handle llx as far as I can tell, and in my build this i= s automatically enabled by the __USE_MINGW_ANSI_STDIO define. > 4. Running "maint selftest" finds one failure: > >=C2=A0=C2=A0 Running selftest help_doc_invariants. >=C2=A0=C2=A0 help doc broken invariant: command 'signal-event' help doc ha= s over-long line >=C2=A0=C2=A0 Self test failed: self-test failed at unittests/command-def-s= elftests.c:121 > > I fixed that with the following trivial change: > > --- gdb/windows-nat.c~0=C2=A0=C2=A0=C2=A0 2024-12-29 04:50:07.000000000 += 0200 > +++ gdb/windows-nat.c=C2=A0=C2=A0=C2=A0 2024-12-29 12:54:32.346946000 +02= 00 > @@ -3114,9 +3114,9 @@ _initialize_windows_nat () > >=C2=A0=C2=A0 add_com ("signal-event", class_run, signal_event_command, _("= \ > Signal a crashed process with event ID, to allow its debugging.\n\ > -This command is needed in support of setting up GDB as JIT debugger on \ > -MS-Windows.=C2=A0 The command should be invoked from the GDB command lin= e using \ > -the '-ex' command-line option.=C2=A0 The ID of the event that blocks the= \ > +This command is needed in support of setting up GDB as JIT debugger on\n= \ > +MS-Windows.=C2=A0 The command should be invoked from the GDB command lin= e using\n\ > +the '-ex' command-line option.=C2=A0 The ID of the event that blocks the= \n\ > crashed process will be supplied by the Windows JIT debugging mechanism."= )); > > #ifdef __CYGWIN__ > > I will report items 1 and 3 to the corresponding upstream projects, > but is it okay to meanwhile install the patches above on the > gdb-16-branch? > > And what about items 2 and 4 -- can I install their fixes?=C2=A0 The fix > with type-cast for FD_ISSET is something I'm unsure about. > > Thanks. Hannes