public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: Mark Wielaard <mark@klomp.org>,
	Mark Wielaard via Overseers <overseers@sourceware.org>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>,
	"Thomas Fitzsimmons" <fitzsim@fitzsim.org>,
	"Dan Horák" <dhorak@redhat.com>
Subject: Re: gdb builder status (Was: Adding binutils to the GNU Toolchain buildbot on sourceware)
Date: Tue, 3 May 2022 11:41:33 -0400	[thread overview]
Message-ID: <f12d07da-8692-5321-95e1-8b2fb5a84cf1@simark.ca> (raw)
In-Reply-To: <20220501194445.GB30898@gnu.wildebeest.org>



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<char>::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<char>]’ 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<char>]’ 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<const char_type*>(__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

  reply	other threads:[~2022-05-03 15:41 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <YmZkKRO+yUHeFqV0@wildebeest.org>
2022-04-25 10:37 ` Adding binutils to the GNU Toolchain buildbot on sourceware Luis Machado
2022-04-25 10:43   ` Frank Ch. Eigler
2022-04-25 12:16     ` Luis Machado
2022-04-25 12:30       ` Frank Ch. Eigler
2022-04-25 18:20       ` Mark Wielaard
2022-04-25 18:27         ` Frank Ch. Eigler
2022-04-25 22:11           ` Mark Wielaard
2022-04-26  3:33         ` Alan Modra
2022-04-26  6:22           ` Jan Beulich
2022-04-26 12:27             ` Nick Clifton
2022-04-26 13:49               ` Jan Beulich
2022-04-26 15:47                 ` H.J. Lu
2022-04-27  6:15                   ` Jan Beulich
2022-04-28 12:10                 ` Nick Clifton
2022-04-28 13:07                   ` Jan Beulich
2022-04-26 15:54           ` H.J. Lu
2022-04-26 23:33             ` Alan Modra
2022-04-27 18:32               ` [PATCH] x86: Disable 2 tests with large memory requirement H.J. Lu
2022-04-26  7:01         ` Adding binutils to the GNU Toolchain buildbot on sourceware Luis Machado
2022-04-26  9:40           ` Frank Ch. Eigler
2022-04-26 22:59             ` Mark Wielaard
2022-04-26 22:34           ` Mark Wielaard
2022-04-28 12:23             ` Luis Machado
2022-04-28 13:50               ` Frank Ch. Eigler
2022-04-28 13:53                 ` Luis Machado
2022-04-28 14:22                   ` Frank Ch. Eigler
2022-04-28 17:04                     ` Mark Wielaard
2022-04-28 14:48                   ` Mark Wielaard
2022-04-28 14:19               ` Mark Wielaard
2022-04-28 14:47                 ` Thomas Fitzsimmons
2022-04-28 16:28                   ` Mark Wielaard
2022-04-29 20:04                     ` gdb builder status (Was: Adding binutils to the GNU Toolchain buildbot on sourceware) Mark Wielaard
2022-05-01 19:44                       ` Mark Wielaard
2022-05-03 15:41                         ` Simon Marchi [this message]
2022-05-13  8:21                       ` Mark Wielaard
2022-04-28 17:50               ` Adding binutils to the GNU Toolchain buildbot on sourceware Nick Alcock
2022-04-29 17:54                 ` Mark Wielaard
2022-04-30  0:12                   ` Nick Alcock
2022-04-30 22:27                     ` Mark Wielaard
2022-05-03 12:48                       ` Nick Alcock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f12d07da-8692-5321-95e1-8b2fb5a84cf1@simark.ca \
    --to=simark@simark.ca \
    --cc=dhorak@redhat.com \
    --cc=fitzsim@fitzsim.org \
    --cc=gdb@sourceware.org \
    --cc=mark@klomp.org \
    --cc=overseers@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).