Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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.

  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