From: Andrew Pinski <pinskia@gmail.com>
To: Luis <luis.machado.foss@gmail.com>
Cc: Guinevere Larsen <guinevere@redhat.com>,
Tom Tromey <tom@tromey.com>,
gdb-patches@sourceware.org
Subject: Re: [PATCH v2 0/8] Remove stabs support from GDB
Date: Wed, 22 Oct 2025 19:03:33 -0700 [thread overview]
Message-ID: <CA+=Sn1m3aMdrH=XwNkLzTy=tc3bDxAr3d25wSRKU31tpn4Vc0Q@mail.gmail.com> (raw)
In-Reply-To: <27fc25e3-4c19-40cd-b9ce-a87da0fa0dff@gmail.com>
On Wed, Oct 22, 2025 at 5:59 PM Luis <luis.machado.foss@gmail.com> wrote:
>
> On 22/10/2025 20:19, Luis wrote:
> > Hi,
> >
> > On Wed, Oct 22, 2025, 14:19 Guinevere Larsen <guinevere@redhat.com
> > <mailto:guinevere@redhat.com>> wrote:
> >
> > On 10/22/25 10:08 AM, Tom Tromey wrote:
> > >>>>>> "Luis" == Luis <luis.machado.foss@gmail.com
> > <mailto:luis.machado.foss@gmail.com>> writes:
> > > Luis> Looks like gcc (13.3.0 at least) is a bit grumpy with this
> > and there
> > > Luis> are a few -Werror=array-bounds= warnings stopping the build,
> > > Luis> apparently from changes to gdb/xcoffread.c.
> > >
> > > Could you post them here?
> > >
> > > IIRC some versions of GCC issued these kinds of errors incorrectly.
> > > So it's possible the fix might be just to disable the warning for
> > that build.
> > >
> > > Tom
> > >
> > I believe that is the case, since I just installed gcc-13.3.1-2 from
> > fedora 40 and upstream built fine, so I think either the .1 shame
> > release (see pride versioning: https://pridever.org/ <https://
> > pridever.org/> :p), or some
> > fedora patch, fixed a gcc bug related to that.
> >
> >
> > Yeah, sorry for the poor report. It happened on a different machine
> > unreachable from the one I sent the message.
> >
> > I'll reproduce it and paste the exact messages. I tried to make sense of
> > it a bit, but seemed a bit odd.
> >
> >
> > --
> > Cheers,
> > Guinevere Larsen
> > It/she
> >
>
> Ok, I played with this a bit more and reproduced it again on my end. The
> problem seems to be related to enabling ubsan in configure for the build.
>
> So if I configure with the following...
>
> ./configure --enable-targets=all --with-python=python3 --without-guile
> --enable-ubsan
>
> I get these errors...
>
> ---
>
> In file included from /usr/include/c++/13/vector:66,
> from /usr/include/c++/13/functional:64,
> from
> ../../../repos/binutils-gdb/gdb/../gdbsupport/ptid.h:35,
> from
> ../../../repos/binutils-gdb/gdb/../gdbsupport/common-defs.h:212,
> from ./../../../repos/binutils-gdb/gdb/defs.h:26,
> from <command-line>:
> In member function ‘std::vector<_Tp, _Alloc>::reference std::vector<_Tp,
> _Alloc>::operator[](size_type) [with _Tp = void*; _Alloc =
> std::allocator<void*>]’,
> inlined from ‘void* registry<T>::get(unsigned int) [with T =
> objfile]’ at ../../../repos/binutils-gdb/gdb/registry.h:213:24,
> inlined from ‘DATA* registry<T>::key<DATA, Deleter>::get(T*) const
> [with DATA = xcoff_symfile_info; Deleter =
> std::default_delete<xcoff_symfile_info>; T = objfile]’ at
> ../../../repos/binutils-gdb/gdb/registry.h:111:36,
> inlined from ‘void enter_line_range(subfile*, unsigned int,
> unsigned int, CORE_ADDR, CORE_ADDR, unsigned int*)’ at
> ../../../repos/binutils-gdb/gdb/xcoffread.c:544:18:
> /usr/include/c++/13/bits/stl_vector.h:1129:32: error: array subscript 0
> is outside array bounds of ‘registry<objfile> [0]’ [-Werror=array-bounds=]
> 1129 | return *(this->_M_impl._M_start + __n);
> | ~~~~~~~~~~~~~~^~~~~~~~
> In function ‘void enter_line_range(subfile*, unsigned int, unsigned int,
> CORE_ADDR, CORE_ADDR, unsigned int*)’:
> cc1plus: note: source object is likely at address zero
> In member function ‘std::vector<_Tp, _Alloc>::reference std::vector<_Tp,
> _Alloc>::operator[](size_type) [with _Tp = void*; _Alloc =
> std::allocator<void*>]’,
> inlined from ‘void* registry<T>::get(unsigned int) [with T =
> objfile]’ at ../../../repos/binutils-gdb/gdb/registry.h:213:24,
> inlined from ‘DATA* registry<T>::key<DATA, Deleter>::get(T*) const
> [with DATA = xcoff_symfile_info; Deleter =
> std::default_delete<xcoff_symfile_info>; T = objfile]’ at
> ../../../repos/binutils-gdb/gdb/registry.h:111:36,
> inlined from ‘void enter_line_range(subfile*, unsigned int,
> unsigned int, CORE_ADDR, CORE_ADDR, unsigned int*)’ at
> ../../../repos/binutils-gdb/gdb/xcoffread.c:544:18:
> /usr/include/c++/13/bits/stl_vector.h:1129:32: error: array subscript 0
> is outside array bounds of ‘registry<objfile> [0]’ [-Werror=array-bounds=]
> In function ‘void enter_line_range(subfile*, unsigned int, unsigned int,
> CORE_ADDR, CORE_ADDR, unsigned int*)’:
> cc1plus: note: source object is likely at address zero
> In member function ‘std::vector<_Tp, _Alloc>::reference std::vector<_Tp,
> _Alloc>::operator[](size_type) [with _Tp = void*; _Alloc =
> std::allocator<void*>]’,
> inlined from ‘void* registry<T>::get(unsigned int) [with T =
> objfile]’ at ../../../repos/binutils-gdb/gdb/registry.h:213:24,
> inlined from ‘DATA* registry<T>::key<DATA, Deleter>::get(T*) const
> [with DATA = xcoff_symfile_info; Deleter =
> std::default_delete<xcoff_symfile_info>; T = objfile]’ at
> ../../../repos/binutils-gdb/gdb/registry.h:111:36,
> inlined from ‘void read_symbol(internal_syment*, int)’ at
> ../../../repos/binutils-gdb/gdb/xcoffread.c:612:38,
> inlined from ‘CORE_ADDR read_symbol_nvalue(int)’ at
> ../../../repos/binutils-gdb/gdb/xcoffread.c:635:15,
> inlined from ‘void enter_line_range(subfile*, unsigned int,
> unsigned int, CORE_ADDR, CORE_ADDR, unsigned int*)’ at
> ../../../repos/binutils-gdb/gdb/xcoffread.c:572:29:
> /usr/include/c++/13/bits/stl_vector.h:1129:32: error: array subscript 0
> is outside array bounds of ‘registry<objfile> [0]’ [-Werror=array-bounds=]
> 1129 | return *(this->_M_impl._M_start + __n);
> | ~~~~~~~~~~~~~~^~~~~~~~
> In function ‘void enter_line_range(subfile*, unsigned int, unsigned int,
> CORE_ADDR, CORE_ADDR, unsigned int*)’:
> cc1plus: note: source object is likely at address zero
> In member function ‘std::vector<_Tp, _Alloc>::reference std::vector<_Tp,
> _Alloc>::operator[](size_type) [with _Tp = void*; _Alloc =
> std::allocator<void*>]’,
> inlined from ‘void* registry<T>::get(unsigned int) [with T =
> objfile]’ at ../../../repos/binutils-gdb/gdb/registry.h:213:24,
> inlined from ‘DATA* registry<T>::key<DATA, Deleter>::get(T*) const
> [with DATA = xcoff_symfile_info; Deleter =
> std::default_delete<xcoff_symfile_info>; T = objfile]’ at
> ../../../repos/binutils-gdb/gdb/registry.h:111:36,
> inlined from ‘int read_symbol_lineno(int)’ at
> ../../../repos/binutils-gdb/gdb/xcoffread.c:649:37,
> inlined from ‘void enter_line_range(subfile*, unsigned int,
> unsigned int, CORE_ADDR, CORE_ADDR, unsigned int*)’ at
> ../../../repos/binutils-gdb/gdb/xcoffread.c:582:36:
> /usr/include/c++/13/bits/stl_vector.h:1129:32: error: array subscript 0
> is outside array bounds of ‘registry<objfile> [0]’ [-Werror=array-bounds=]
> 1129 | return *(this->_M_impl._M_start + __n);
> | ~~~~~~~~~~~~~~^~~~~~~~
> In function ‘void enter_line_range(subfile*, unsigned int, unsigned int,
> CORE_ADDR, CORE_ADDR, unsigned int*)’:
> cc1plus: note: source object is likely at address zero
>
> ---
>
> If I drop the --enable-ubsan from configure, then the build completes
> just fine.
>
> Maybe not a show stopper, but would be nice to have working builds with
> ubsan.
Yes GCC warnings with -fsanitize=undefined are known to be worse.
This is documented at
https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Instrumentation-Options.html#index-fsanitize_003dundefined
:
```
Note that sanitizers tend to increase the rate of false positive
warnings, most notably those around -Wmaybe-uninitialized. We
recommend against combining -Werror and [the use of] sanitizers.
```
Array bounds also have an increased amount of warnings too.
Yes, this is an area where GCC should be better at handling this; we
(GCC) have discussed this a few times but there is almost no consensus
of what should happen next and nothing changes.
Thanks,
Andrew
>
> For reference, the system is using Mint 22.2, which might be equivalent
> to Ubuntu 24.04.
next prev parent reply other threads:[~2025-10-23 2:04 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-20 15:28 Guinevere Larsen
2025-10-20 15:28 ` [PATCH v2 1/8] gdb: move some stabs functions to gdb/buildsym-legacy.h Guinevere Larsen
2025-10-20 16:25 ` Tom Tromey
2025-10-20 15:28 ` [PATCH v2 2/8] gdb/mdebug: Remove stabs support from mips inferiors Guinevere Larsen
2025-10-20 15:28 ` [PATCH v2 3/8] gdb: Remove stabs support from ELF files Guinevere Larsen
2025-10-20 15:28 ` [PATCH v2 4/8] gdb: Remove stabs support from dbx Guinevere Larsen
2025-10-20 15:28 ` [PATCH v2 5/8] gdb: Remove stabs support for COFF files Guinevere Larsen
2025-10-20 15:28 ` [PATCH v2 6/8] gdb: Remove stabs support from XCOFF inferiors Guinevere Larsen
2025-11-07 10:46 ` Andrew Burgess
2025-11-07 12:09 ` Guinevere Larsen
2025-11-07 14:46 ` Tom Tromey
2025-10-20 15:28 ` [PATCH v2 7/8] gdb: Fully remove stabs code from GDB Guinevere Larsen
2025-10-20 16:39 ` Eli Zaretskii
2025-10-20 19:12 ` Guinevere Larsen
2025-10-20 15:28 ` [PATCH v2 8/8] gdb: remove support for dbx " Guinevere Larsen
2025-10-21 19:14 ` [PATCH v2 0/8] Remove stabs support " Tom Tromey
2025-10-21 19:42 ` Guinevere Larsen
2025-10-22 9:48 ` Luis
2025-10-22 13:08 ` Tom Tromey
2025-10-22 13:19 ` Guinevere Larsen
2025-10-22 19:19 ` Luis
2025-10-23 0:58 ` Luis
2025-10-23 2:03 ` Andrew Pinski [this message]
2025-10-23 18:11 ` Simon Marchi
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='CA+=Sn1m3aMdrH=XwNkLzTy=tc3bDxAr3d25wSRKU31tpn4Vc0Q@mail.gmail.com' \
--to=pinskia@gmail.com \
--cc=gdb-patches@sourceware.org \
--cc=guinevere@redhat.com \
--cc=luis.machado.foss@gmail.com \
--cc=tom@tromey.com \
/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