From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id wEj0DJJsd2e4dgEAWB0awg (envelope-from ) for ; Thu, 02 Jan 2025 23:50:26 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; secure) header.d=adacore.com header.i=@adacore.com header.a=rsa-sha256 header.s=google header.b=li+ZMtFh; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 3191B1E097; Thu, 2 Jan 2025 23:50:26 -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,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 CAB611E091 for ; Thu, 2 Jan 2025 23:50:25 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7A26B3858C50 for ; Fri, 3 Jan 2025 04:50:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7A26B3858C50 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, secure) header.d=adacore.com header.i=@adacore.com header.a=rsa-sha256 header.s=google header.b=li+ZMtFh Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) by sourceware.org (Postfix) with ESMTPS id 321E83858CDA for ; Fri, 3 Jan 2025 04:48:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 321E83858CDA Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 321E83858CDA Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::334 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1735879736; cv=none; b=qq3Wn//pHYF5qTTMHmrCtOgfIpU6FqIC0Ed6n8+f9m5j/Q1/mW9nOUHjTLmJ0FQiNkzxXO2k2UxRocNw6+WAjH8OuGNw8Tu3xO8QQqLiKAN5jlwwv0CIav8c7d7HPqbP50mNBgxKqNh40Vdmfe8VF6kAT77DxGpyIWAdAOFgZ/k= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1735879736; c=relaxed/simple; bh=KBhXTPaTgKdKYsP5wDwIM1n2l+ApowijOUjlBBmopKU=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=W0BI3DlUT1A2LEHqkng+pD641iqQWvhVZpY9AmfHn4ktt4RLN4+xLkFw4NMA+Aev3FfY5XctWrEtJce2TmHa5hnYyV4fZZMcatDfsqS1Bl5sEcJkzrsSKtaCuW1pGqqhhxHoutQ1qeUottuCi8EeqzcBkVV9mlXzX53nIBHv4v8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 321E83858CDA Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-4361b0ec57aso118752645e9.0 for ; Thu, 02 Jan 2025 20:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1735879735; x=1736484535; darn=sourceware.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=8bajdQqKVhzl0tObaCIn4kbW5eotKergEvOsor3dLWI=; b=li+ZMtFh3RQTD6q46tXUSHP+UJJN46uC8nI7BcQMnkq2IR9xmlrkxk2CypnK+OfyeA ikiFt7wA4HWtjcTlJf5RCE0YJb3A3TIgA5+ARVn4nUI0ApWB49GFv6vYyjkJrb3cGi7J aye+58K143zGZdv4VvQqocmoGepexPdKl5tj5+G7WefMT7llSwtIT8hOjbIZgUXlgzrd rOzUtnZ8/ntg0JNRxxCJKjLbSs3URMkFMxi9KwAN5Vjh3o9uT7ce+WqP/MMfw1Okebq3 NfIegqL8ZvI82gNJ//9IUbZQnzaVyAAudkM6grzvGivkBhUs1ZkskgdnB11lNKd06aNs Lw1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735879735; x=1736484535; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8bajdQqKVhzl0tObaCIn4kbW5eotKergEvOsor3dLWI=; b=Z6O6hfO97fO6+/mgJWxLYFhtZWxdyLvjoWEqhu+o/f/0FFA5mqiQQiVePTDrbLe3Zz Lh/18RQ1jDIdRkzGajpx/fl7xTBMLz/y9reFFRqjG6bN9Etyg3T+eoLO0b3ILs80W6qy BnzAqKvYU5TyEx+Eye+DUtQXBSliQR8iDaONGG3AUwMww/6jpUZS7wsmtCpL8erPYtgG RtLTTnTyECXMKuBP8F260y6Nqw7O5e7zuDbaWILiag9nXkCRUNd5R7zDvdUJFOoszzM9 KVt23qC5aVuc5dWjKA1g+Y9voh2xYmrBm8WwZ7Xx8cD+qa3SwscpJCGiE1HJbSM5KdTZ 6+Zg== X-Forwarded-Encrypted: i=1; AJvYcCXUi1mOKFr5ZEOmGfA1704cYi6fOVhVROu82lE+veFSAXMuGLQGawO9ku243pb1CsrQF10Hmp45E3sRRw==@sourceware.org X-Gm-Message-State: AOJu0Yx35KV1TkT2dtzch2tmYP/zVegR0+tOxsbTuTq7yym0L3Mj44Bn NKS0u5dpMIlFdHU9RSxVvXP2LmqCRiAS89ap7uvzQilNFpeycYS5vCvt7CzUFFv7AjRlJe4Thg= = X-Gm-Gg: ASbGncst0K6G+fa2Gk38dCTrIq6EeDlRxbZJgTfg/1a9NygUVCzBHBTNP9D1483amd/ vqrC4C/teebkSKPjW1MTahPU3BH1DHcPybYzYYPGj6/5mqkKDHmxrnofTruRpxSYA1SMZz2RHT7 KkFEhyatKhTHKH1NX9By0NqYJtzQvsgkmJw0LfEVRjUmyJxRIfDfqva8FCyga74UWhqKKhs/61V 20ukJe92LneDVrfJBDa/JBHwdqF7XvAJrvKEBmtBXv/7i+pspoVS2PCWtPmSta2orVUMglC+Vnc Kz6qs+D5uf4rhpKUnIVRZv/2ekgFeZyj X-Google-Smtp-Source: AGHT+IHT4RmsxCCkfGvetFBfP+YcQ2uDOYzQbuE+tKgowB+fhgDCwYovwMq0vMmWXLdaatt/eIpffA== X-Received: by 2002:a05:600c:3c82:b0:435:fa90:f19f with SMTP id 5b1f17b1804b1-43675cb1ef4mr381921975e9.12.1735879734582; Thu, 02 Jan 2025 20:48:54 -0800 (PST) Received: from takamaka.gnat.com (lfbn-reu-1-488-54.w92-130.abo.wanadoo.fr. [92.130.77.54]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4366128a353sm471942375e9.42.2025.01.02.20.48.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Jan 2025 20:48:53 -0800 (PST) Received: by takamaka.gnat.com (Postfix, from userid 1000) id C0D37803F2; Fri, 3 Jan 2025 08:48:51 +0400 (+04) Date: Fri, 3 Jan 2025 08:48:51 +0400 From: Joel Brobecker To: Eli Zaretskii Cc: brobecker@adacore.com, Tom Tromey , ssbssa@yahoo.de, gdb-patches@sourceware.org Subject: Re: GDB 16.0.90 available for testing Message-ID: 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <865xmxjeuv.fsf@gnu.org> 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 > > > > 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. -- Joel