From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id SKLnKL8NeWdAwgIAWB0awg (envelope-from ) for ; Sat, 04 Jan 2025 05:30:23 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=Dno7wR6r; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id A39011E097; Sat, 4 Jan 2025 05:30:23 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 27F961E05C for ; Sat, 4 Jan 2025 05:30:23 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id ACC683858CD1 for ; Sat, 4 Jan 2025 10:30:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ACC683858CD1 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=Dno7wR6r Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 1F3D73858D20 for ; Sat, 4 Jan 2025 10:29:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1F3D73858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1F3D73858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1735986588; cv=none; b=A6DVqAoa7bFroRdMDTbAexArNLKSfnbwLXFDbz4RiHyGAWEBu3A2GUmdewl9sxDQa0+VgbCI9PHHEyX/63Ur4CGpvkjXe7X6FvVV8MU8St5ijFscUNqouFHJxvzonbaLgufQxL3JFeHZdi/K9uPsVto1PvxRI5hRYGw5ca9RS5c= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1735986588; c=relaxed/simple; bh=DmLa0jCVPvEIRMXNa7t8NzEcLXXbcL8OVqiW7OYCVgI=; h=DKIM-Signature:Date:Message-Id:From:To:Subject:MIME-version; b=Rup5FgjJe0ZfcBD8Npiq/CoKcUj7qnK+Rujm4uy7YJP0OOFTjLjEuUI4VadLTrosoG6YvppNJYqyyuok5sfFbItSh3+Tpnd0Czm/LGuGXoKT0idhZ7QAa663Y2EQyiigmjjwuxck3bhF9Jn1hHWeaY+3IMB17EDoJsCb8G9IRi4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1F3D73858D20 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tU1Pe-0007gw-65; Sat, 04 Jan 2025 05:29:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=/29yqe3ObDzjQet97Y4pAKWNrbnzqH8t6G3Lux0ys0g=; b=Dno7wR6rk8FI6yzB+zjI eNFGVGzpL3Ugr8xZuNDkgSXlzqNuhMU0nunjgHJ9uf5p3IeepjuffLlMpy/qixpOWSqendZLgcs/X wUIKLGdpnCSV6OON+utZ8p0ZBjQm2rsnwqOdv5v4EpqqgX6kkv8SVzJsLIVKB0G3hqpLQ2Sy3qvbl IBRTpcJIlS1GmNe2u+kIQXHhHeZTodtg2Hk9XVrm95VgM4bEwGVPMqwZIAh+o2bnMG/jbGWyRp0tG mlAGG7+1kVDxl4+bUqO5DeEaDLWd/U37QmU4Cvndk0AW7y7m5x2P1lBBi0vHFaOJYnOqSbzTuGkVC xVzDZGmeg3pb7w==; Date: Sat, 04 Jan 2025 12:29:42 +0200 Message-Id: <861pxig9d5.fsf@gnu.org> From: Eli Zaretskii To: Joel Brobecker Cc: tom@tromey.com, ssbssa@yahoo.de, gdb-patches@sourceware.org In-Reply-To: (message from Joel Brobecker on Fri, 3 Jan 2025 08:48:51 +0400) Subject: Re: GDB 16.0.90 available for testing References: <20241229033130.D7F7F803EA@takamaka.gnat.com> <868qryr6nn.fsf@gnu.org> <745538212.4148266.1735485100440@mail.yahoo.com> <86zfkepkqh.fsf@gnu.org> <865xmxjeuv.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 > Date: Fri, 3 Jan 2025 08:48:51 +0400 > From: Joel Brobecker > Cc: brobecker@adacore.com, Tom Tromey , ssbssa@yahoo.de, > gdb-patches@sourceware.org > > > > > > 1. A compilation error in readline/input.c, due to lack of 'alarm' > > > > > function.  I have reported that several months ago to the upstream > > > > > Readline developers, but the solution they installed only works for > > > > > MinGW64.  For mingw.org we need the following patch: > > > > > > > > > > --- readline/readline/input.c~0    2024-12-29 04:50:07.000000000 +0200 > > > > > +++ readline/readline/input.c    2024-12-29 12:32:04.196630800 +0200 > > > > > @@ -151,6 +151,14 @@ win32_isatty (int fd) > > > > > #  define RL_TIMEOUT_USE_SELECT > > > > > #else > > > > > #  define RL_TIMEOUT_USE_SIGALRM > > > > > +#  ifdef __MINGW32_MAJOR_VERSION > > > > > +/* mingw.org's MinGW doesn't have 'alarm'.  */ > > > > > +unsigned int > > > > > +alarm (unsigned int seconds) > > > > > +{ > > > > > +  return 0; > > > > > +} > > > > > +#  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. > > > > > > Chet said that's what he did, but I saw no evidence of that in the > > > current Readline (assuming I was looking at the correct branch in the > > > Git repository). See > > > > > > https://lists.gnu.org/archive/html/bug-readline/2024-12/msg00003.html > > > > Given what Chet says in > > > > https://lists.gnu.org/archive/html/bug-readline/2024-12/msg00006.html > > > > I now understand how this is fixed in upstream Readline. The fix > > there is not right: it will fail the MinGW64 build. So I'd like to > > fix this properly in our repository and tell Chet how I recommend to > > fix it upstream. > > > > Should I fix this in our repository right away, or would you prefer to > > wait for Chet to agree with my proposal, so that we have the same code > > as in upstream Readline? > > For the avoidance of doubt, I cannot approve patches in GDB anymore. > > With that said, it's been fine in the past to first fix things > locally in GDB, before coordinating with the upstream project > as a second step. When the fix is pushed upstream, we can then > resync our copy if the fix was different. Thanks, I've now installed the change on both master and gdb-16-branch. Upon taking a better look on what the upstream Readline did, I came to the conclusion that it does TRT for both flavors of MinGW, so there's nothing to report to the Readline developers.