From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ONCaL1Y/dWezoD4AWB0awg (envelope-from ) for ; Wed, 01 Jan 2025 08:12:54 -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=G5/LnOl6; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id BE9D81E097; Wed, 1 Jan 2025 08:12:54 -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 432B91E05C for ; Wed, 1 Jan 2025 08:12:54 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D9A803858C56 for ; Wed, 1 Jan 2025 13:12:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D9A803858C56 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=G5/LnOl6 Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id CDFE93858C50 for ; Wed, 1 Jan 2025 13:12:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CDFE93858C50 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 CDFE93858C50 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=1735737136; cv=none; b=B84ZJpc6X8EvYYTnSArnhA84yY8Ed2/vpkF/taRFql36erKqdwMDxOYY6zcrFwRfX7khg9zcpXnbivJOKaH3iYmg89/4L552QOCRlZluKifdtwQ4pxUP7NaiQwLdSFoXn+1F2pW08c4ZS9pMRta/eOh3vBbvhkqam6cUuFKJMoc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1735737136; c=relaxed/simple; bh=CxcBLfrCITHvHh1zAUVWgPF6h1cNOcyELK9spTADL34=; h=DKIM-Signature:Date:Message-Id:From:To:Subject:MIME-version; b=iY5AkFiQ94JpxDxfR1xLB1fpX3doIOPMIuIaQEkMQ7M8Y+amCl7S/9BS+NjfIDEMQKOs/xDMaNGWnRhuz8pzU8OD3NKDmcV3WcQACosItk9wA6QQBCGjr5LQaYBzVvBdnLESea33nRO9V6JUmTyhlACfoR7PXaXGybaYed1F6W4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CDFE93858C50 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 1tSyWG-0006FW-2c; Wed, 01 Jan 2025 08:12:16 -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=L24Y0ExZrzFM3zeJoA8VCPnx+RFj55ByvacLGaHUxbs=; b=G5/LnOl6lrD7b/8OuHVQ UR4iJnZPJ0IVHS2rIVuXjNi1qX6Ob/0EtbfvykJLLzxtmSqX7Bn6pP2fmM0YWUljPqf3nKg21TzXv KaW5ewISi2lqo17TR9PwS3+2Q09Zcalcc5BNhBmsB3EVzZiQpVAf3GC1dDQChIYO8EoZjrLowyb25 E6PRqLq/uPiSwSChxKT2lqHw05WQ41IcypzYx30dsQ8F6+8f7bkNIIVQ8YYv6qrOeIZ1UpNQ7t18+ 27H+ENgOcd91mOxBUlJT77dcLRb+16jP+OjWQTL5U4Txpof+GvFgy7PzjOYtc3iED8Qkz8VdIm2Pl P5L3Wq6UWfZoUw==; Date: Wed, 01 Jan 2025 15:12:13 +0200 Message-Id: <86seq2llua.fsf@gnu.org> From: Eli Zaretskii To: brobecker@adacore.com Cc: ssbssa@yahoo.de, gdb-patches@sourceware.org In-Reply-To: <86zfkepkqh.fsf@gnu.org> (message from Eli Zaretskii on Sun, 29 Dec 2024 17:33:26 +0200) 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> 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.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: Sun, 29 Dec 2024 17:33:26 +0200 > From: Eli Zaretskii > Cc: brobecker@adacore.com, gdb-patches@sourceware.org > > > > 3. Running GDB on itself produces the following error message: > > > > > >   warning: BFD: error: d:\gnu\gdb-16.0.90\gdb\gdb.exe(.debug_macro) is too large (0x9f585e077fdeba bytes) > > >   warning: Can't read data for section '.debug_macro' in file 'd:\gnu\gdb-16.0.90\gdb\gdb.exe' > > >   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.  I tracked > > > the bogus print value to this code in bfd: > > > > > >           /* PR 20801: Provide a more helpful error message.  */ > > >           if (bfd_get_error () == bfd_error_no_memory) > > >         _bfd_error_handler > > >           /* xgettext:c-format */ > > >           (_("error: %pB(%pA) is too large (%#" PRIx64 " bytes)"), > > >           abfd, sec, (uint64_t) allocsz); > > > > > > It sounds like uint64_t values are not printed correctly by BFD in > > > this 32-bit build?  I ended up using the following kludge: > > > > > >           if (sizeof (allocsz ) > sizeof (int)) > > >             _bfd_error_handler > > >             /* xgettext:c-format */ > > >               (_("error: %pB(%pA) is too large (%#" PRIx64 " bytes)"), > > >               abfd, sec, (uint64_t) allocsz); > > >           else > > >             _bfd_error_handler > > >             /* xgettext:c-format */ > > >               (_("error: %pB(%pA) is too large (%#" PRIx32 " bytes)"), > > >               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 is > > automatically enabled by the __USE_MINGW_ANSI_STDIO define. > > AFAICT, llx didn't help, either (I tried), and __USE_MINGW_ANSI_STDIO > is the default anyway. It's very strange what I saw there, using llx > I got printed values like 0x77fdeba00000000, which seem like the value > was interpreted as big-endian or something? You are welcome to try, > maybe I was confused or something. Alan Modra fixed this bug in Binutils on the master branch, see commit b38cf91f230b and https://sourceware.org/bugzilla/show_bug.cgi?id=32507 I'd like to apply the patch to gdb-16-branch, so that GDB 16.1 is released without it. Do I cherry-pick the commit from master, or do I follow some other procedure? That is, when the release tarball of GDB 16.1 is tarred, will it fetch the bfd files from the bfd directory of the gdb-16-branch branch? Thanks.