From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id yGaiKfNrcWdYvzgAWB0awg (envelope-from ) for ; Sun, 29 Dec 2024 10:34:11 -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=Pdgr3lN9; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id A61AB1E097; Sun, 29 Dec 2024 10:34:11 -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 11CA61E05C for ; Sun, 29 Dec 2024 10:34:11 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A55E9385840A for ; Sun, 29 Dec 2024 15:34:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A55E9385840A 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=Pdgr3lN9 Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 68DA83858D34 for ; Sun, 29 Dec 2024 15:33:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 68DA83858D34 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 68DA83858D34 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=1735486417; cv=none; b=nh+fRoZ6bUVgDqsr9KCiGJKdKtC7M3zWb7gtNMyhO1E/ZMMmfCX44CmKWe5E34yWABgWxWSWPSiEkzUG5K8CRi+HET42Fguv+mO5digz1X+7KpcL3/z0rwdfwFU+gYq9xTrdt/M/ShRcoej/kMOIOjx2jnNThC/hNEiSwLFHuVs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1735486417; c=relaxed/simple; bh=T3au+HxL//Sk94+tBUlFQ1uu2/hw1tJYeFt11Ph17x0=; h=DKIM-Signature:Date:Message-Id:From:To:Subject:MIME-version; b=fdJekWkzShKvXVymMsVNWAmiMIoHZkRwl6NTEEiZZLPqyYMx9Z6dHGnQHE/7N7ioVZb7GWeD1l6DDxM//T7LYl9hy7BA7CabvUTm/RThcGaG4gl64Coju6AxOddwj9Jc/GDtwBROilYWXKc7B5UXVDASL89GTL65kWAGkgy4+lc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 68DA83858D34 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 1tRvIO-0002Oa-0t; Sun, 29 Dec 2024 10:33:36 -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=+SnRP/Gu9jmEvk6ntny98W83zoOj8Ol6JNpCRkYQmWU=; b=Pdgr3lN9kWmpKy+fVnBR wuhXB6RtpQvzxF4No+x8/uRfnU7HHvchB3SXV9QuNY0O2cXVBEiZKSiX52SbfykUsWlHS14s37Rna HuhrkHrNZEywnJ5aLvZwGXq1wA0ALpxVbqi16WtbOvcKOwqEG7xqckFRfT4t8GaZDzXc5YY17EROl mHM+kEC7vnojeN18nHBK7tzVg3dXnHiR7insgKUqByw8l/gohjLEdhDjurYM5Rj57s+LYGRawNeEe Np/zW2sXQa4PeWc5CSbQhS1lYad8t+hqxMRrEChLbHbQ1ym7JCtOk5/SmQJ9mhnn00bItT/38+SqG stuDdWvIuJpUZg==; Date: Sun, 29 Dec 2024 17:33:26 +0200 Message-Id: <86zfkepkqh.fsf@gnu.org> From: Eli Zaretskii To: Hannes Domani Cc: brobecker@adacore.com, gdb-patches@sourceware.org In-Reply-To: <745538212.4148266.1735485100440@mail.yahoo.com> (message from Hannes Domani on Sun, 29 Dec 2024 15:11:40 +0000 (UTC)) 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> 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 15:11:40 +0000 (UTC) > From: Hannes Domani > Cc: "gdb-patches@sourceware.org" > > Am Sonntag, 29. Dezember 2024 um 13:55:25 MEZ hat Eli Zaretskii Folgendes geschrieben: > > > 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 > > 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.