Re: [PATCH] [gdb/build] Work around GCC ipa-modref bug

[Sam James <sam@gentoo.org>]

Andrew Burgess <aburgess@redhat.com> writes:

> Tom de Vries <tdevries@suse.de> writes:
>
>> PR mi/32571 reports the following problem:
>> ...
>> $ gdb -q -batch -ex "b bla.c:100"
>> <random output>
>> Make breakpoint pending on future shared library load? (y or [n]) \
>>   [answered N; input not from terminal]
>> ...
>> while this is expected:
>> ...
>> $ gdb -q -batch -ex "b bla.c:100"
>> No symbol table is loaded.  Use the "file" command.
>> Make breakpoint pending on future shared library load? (y or [n]) \
>>   [answered N; input not from terminal]
>> ...
>>
>> A few factors in reproducing this are building gdb using gcc 14,
>> "-O2 -flto=auto" and --disable-nls.  For more details, see the PR.
>>
>> This turns out to be caused by a GCC PR [1], more specifically a problem in
>> ipa-modref.
>>
>> Work around this by disabling ipa-modref for GCC versions 12-15 and 16.0,
>> assuming the GCC 16.1 release will contain a fix.
>
> First, massive thanks for tracking this issue down.
>
>>
>> Tested on aarch64-linux and x86_64-linux.
>>
>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32571
>>
>> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
>> ---
>>  gdbsupport/common-defs.h | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/gdbsupport/common-defs.h b/gdbsupport/common-defs.h
>> index 07caf3bd7e4..bdf04d9ec09 100644
>> --- a/gdbsupport/common-defs.h
>> +++ b/gdbsupport/common-defs.h
>> @@ -27,6 +27,14 @@
>>  #pragma GCC optimize("-fno-hoist-adjacent-loads")
>>  #endif
>>  
>> +#if defined (__GNUC__) && !defined (__clang__) \
>> +  && ((__GNUC__ >= 12 && __GNUC__ <= 15)       \
>> +      || (__GNUC__ == 16 && __GNUC_MINOR__ < 1))
>> +/* Work around PR gcc/110799 starting gcc 12, and assume it will be fixed in
>> +   the gcc 16.1 release.  */
>
> Should that not be gcc/120987?

Ah, yeah.

> Also I notice the target milestone on
> that gcc bug is set to 13.5, maybe that field is used differently for
> gcc, but I was expecting to see 16.1 maybe?  I know there's limits on
> what we can do to ensure gcc fix this, but might as well get these
> fields as correct as possible :)

It's correct as it is in terms of the upstream bug milestone. The milestone is the
first supported version it affects. gdb doesn't have that issue as it
tends to not support multiple branches and doesn't always do point
releases for the branches.

> [...]

sam