From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Cc: "gdb@sourceware.org" , Thomas Fitzsimmons , =?UTF-8?Q?Dan_Hor=c3=a1k?= 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> From: Simon Marchi In-Reply-To: <20220501194445.GB30898@gnu.wildebeest.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-13.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Tue, 03 May 2022 15:41:35 -0000 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