From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id csxRGUlNcWIfDQQAWB0awg (envelope-from ) for ; Tue, 03 May 2022 11:42:01 -0400 Received: by simark.ca (Postfix, from userid 112) id 5BED31E089; Tue, 3 May 2022 11:42:01 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=voqjRq4t; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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,NICE_REPLY_A,RDNS_DYNAMIC, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.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 AB45B1E086 for ; Tue, 3 May 2022 11:42:00 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1546C3952496 for ; Tue, 3 May 2022 15:42:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1546C3952496 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1651592520; bh=BB29ooDOIpuWzD1hseO6+XkMewIkcOC0d7dHm6eOwc8=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=voqjRq4tWsJZv+qN+p0+jgZOszSc11+ErolMseifaZhJcZXKzJ9vsWQWaIKdqp/o6 gB/WPIpnOiIRUO/klQe32EimJj+x7B6+Ryka3bctlC1IlE/ssBMzt3jnYSHQM6Ysc9 J0DuiUQDso3iLPeU9GinLsh7+VB1VgioyU2WgnVQ= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 29F853952005; Tue, 3 May 2022 15:41:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 29F853952005 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 8E0AF1E048; Tue, 3 May 2022 11:41:33 -0400 (EDT) Message-ID: Date: Tue, 3 May 2022 11:41:33 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: gdb builder status (Was: Adding binutils to the GNU Toolchain buildbot on sourceware) Content-Language: en-US To: Mark Wielaard , Mark Wielaard via Overseers References: <5c1f217a-109c-2973-6c69-abf412133dee@arm.com> <524b04b7-a78c-7aae-4605-b40f61e6830c@arm.com> <16fe426d-c436-f030-dc43-0e81e7f0e853@arm.com> <20220428141957.GB23335@gnu.wildebeest.org> <20220428162803.GD23335@gnu.wildebeest.org> <20220429200422.GB7305@gnu.wildebeest.org> <20220501194445.GB30898@gnu.wildebeest.org> In-Reply-To: <20220501194445.GB30898@gnu.wildebeest.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb Reply-To: Simon Marchi Cc: "gdb@sourceware.org" , Thomas Fitzsimmons , =?UTF-8?Q?Dan_Hor=c3=a1k?= Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 2022-05-01 15:44, Mark Wielaard wrote: > Hi, > > On Fri, Apr 29, 2022 at 10:04:22PM +0200, Mark Wielaard via Overseers wrote: >> The fedora-s390x failure looks as follows: >> https://builder.sourceware.org/buildbot/#/builders/gdb-fedora-s390x >> >> In file included from /usr/include/c++/11/string:40, >> from ../../binutils-gdb/gdb/../gdbsupport/ptid.h:36, >> from ../../binutils-gdb/gdb/../gdbsupport/common-defs.h:198, >> from ../../binutils-gdb/gdb/defs.h:28, >> from ../../binutils-gdb/gdb/debuginfod-support.c:19: >> In static member function ‘static constexpr const char_type* std::char_traits::find(const char_type*, std::size_t, const char_type&)’, >> inlined from ‘constexpr std::basic_string_view<_CharT, _Traits>::size_type std::basic_string_view<_CharT, _Traits>::find(_CharT, std::basic_string_view<_CharT, _Traits>::size_type) const [with _CharT = char; _Traits = std::char_traits]’ at /usr/include/c++/11/bits/string_view.tcc:87:41, >> inlined from ‘constexpr std::basic_string_view<_CharT, _Traits>::size_type std::basic_string_view<_CharT, _Traits>::find_first_of(_CharT, std::basic_string_view<_CharT, _Traits>::size_type) const [with _CharT = char; _Traits = std::char_traits]’ at /usr/include/c++/11/string_view:431:26, >> inlined from ‘bool debuginfod_is_enabled()’ at ../../binutils-gdb/gdb/debuginfod-support.c:194:33: >> /usr/include/c++/11/bits/char_traits.h:413:62: error: ‘void* __builtin_memchr(const void*, int, long unsigned int)’ specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overread] >> 413 | return static_cast(__builtin_memchr(__s, __a, __n)); >> | ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~ >> > > This is really weird. I don't know why, but for some reason g++ (GCC) > 11.2.1 20220127 (Red Hat 11.2.1-9) on s390x seems convinced the string > might be of SIZE_MAX lenght. And so complains because the length of an > array can only be PTRDIFF_MAX. The following "fixes" it: > > diff --git a/gdb/debuginfod-support.c b/gdb/debuginfod-support.c > index 4ce2e786..d4f8a55c 100644 > --- a/gdb/debuginfod-support.c > +++ b/gdb/debuginfod-support.c > @@ -190,7 +190,10 @@ debuginfod_is_enabled () > size_t off = url_view.find_first_not_of (' '); > if (off == gdb::string_view::npos) > break; > - url_view = url_view.substr (off); > + /* Use PTRDIFF_MAX otherwise g++ might (wrongly) believe > + the string might be SIZE_MAX and warn for specified bound > + exceeding maximum object size on find. */ > + url_view = url_view.substr (off, PTRDIFF_MAX); > off = url_view.find_first_of (' '); > gdb_printf > (_(" <%ps>\n"), > > Is that a reasonable workaround? Hi Mark, If it's really just the diagnostic that is bogus, my preference would be to try to silence the diagnostic and not modify the code. It would require adding a DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD to include/diagnostics.h. I would also limit the disabling to just that arch, like: #if defined (__s390x__) || defined (__s390__) # DIAGNOSTIC_PUSH # DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD #endif // the code #if defined (__s390x__) || defined (__s390__) # DIAGNOSTIC_POP #endif And if that bug ever gets fixed in gcc (let's say in gcc 13), I would change the condition (hopefully we remember) to only disable the warning on gcc <= 12. This way, when someone sees this in 20 years, when we don't care about gcc 12 anymore, they'll know they can remove the workaround. Sometimes this doesn't work though, as it would require putting pragma in the libstdc++ header, which we obviously can't do. In that case I would fall back to what you propose. Simon