From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 6l0hKtJcP2K6dwAAWB0awg (envelope-from ) for ; Sat, 26 Mar 2022 14:34:58 -0400 Received: by simark.ca (Postfix, from userid 112) id 9B83A1F3E0; Sat, 26 Mar 2022 14:34:58 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from 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 RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 19CAD1F3B5 for ; Sat, 26 Mar 2022 14:34:58 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9FE4F385842B for ; Sat, 26 Mar 2022 18:34:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9FE4F385842B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1648319697; bh=1ZhWpPr/22ryWdX+4fCAAVcxQcBJGFuaeHIcnUBoslQ=; h=Date:To:In-Reply-To:Subject:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=VKC7bIhU4L4KRNwpnUfaDS1GhFHanj0weVJ6OQnmIi9ZnXVoxpQbe8ZrWVr+jFrMk FHf+TTJ2+a9DrIH+t6VMuAoNPESRPB31mIbJdAltSAYDMNo8f8HNTMOZ3sLQWtDS7+ qf9vSupM397GMAUuB/pxCVwzd0LHzrbfNFn3DUQo= Received: from eggs.gnu.org (eggs.gnu.org [209.51.188.92]) by sourceware.org (Postfix) with ESMTPS id 9D0DC3858D28 for ; Sat, 26 Mar 2022 18:34:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9D0DC3858D28 Received: from [2001:470:142:3::e] (port=58892 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nYBFE-0007g1-As; Sat, 26 Mar 2022 14:34:36 -0400 Received: from [87.69.77.57] (port=4202 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nYBFD-0006YB-Ql; Sat, 26 Mar 2022 14:34:36 -0400 Date: Sat, 26 Mar 2022 21:34:32 +0300 Message-Id: <83pmm8a7gn.fsf@gnu.org> To: brobecker@adacore.com In-Reply-To: <83sfr4a93r.fsf@gnu.org> (message from Eli Zaretskii via Gdb-patches on Sat, 26 Mar 2022 20:59:04 +0300) Subject: Re: GDB 12.0.90 available for testing References: <20220320055815.2A90FA4D6C@takamaka.home> <83sfr4a93r.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Eli Zaretskii via Gdb-patches Reply-To: Eli Zaretskii Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > Date: Sat, 26 Mar 2022 20:59:04 +0300 > From: Eli Zaretskii via Gdb-patches > Cc: gdb-patches@sourceware.org > > First, there's this compilation warning when compiling infrun.c: > > CXX infrun.o > In file included from btrace.h:30, > from gdbthread.h:29, > from infrun.h:21, > from infrun.c:23: > target/waitstatus.h: In function 'void stop_all_threads()': > target/waitstatus.h:175:13: warning: 'ws.target_waitstatus::m_value' may be used uninitialized in this function [-Wmaybe-uninitialized] > 175 | m_value = other.m_value; > | ~~~~~~~~^~~~~~~~~~~~~~~ > > Is this a real problem? > > Second, one of the selftests fails: > > Running selftest dw2_expand_symtabs_matching. > warning: charset conversion failure for 'u8fun├º├úo'. > You may have the wrong value for 'set ada source-charset'. > warning: could not convert 'yfunc ' from the host encoding (CP1255) to UTF-32. > This normally should not happen, please file a bug report. > > AFAIU, this is because the names of these two functions are, > respectively, in UTF-8 and in Latin-1, but the charset conversion > thinks they are in CP1255. Where does the test tell the conversion > functions what is the source encoding? And another problem: starting this GDB under Emacs, with "M-x gdb" (which invokes "gdb -i=mi") seems to confuse Emacs, so much so that the debugging session is barely usable: symbols are unknown, so I cannot set breakpoints, etc. There's no such problem with GDB 11.1. I wonder if this is a Windows specific issue. Did someone try GDB 12 inside Emacs on GNU/Linux, and if so, did it work as expected?