Re: [PATCH v2 6/8] gdb: Remove stabs support from XCOFF inferiors

Andrew Burgess
2025-11-07T10:48:02Z

Guinevere Larsen <guinevere@redhat.com> writes:

> This commit is the second to last in the series fully removing support
> for stabs in GDB, removing it from XCOFF inferiors. According to IBM's
> AIX documentation[1], xcoff binaries can only have stabs or DWARF debug
> info, meaning removing stabs seems pretty trivial, as anything that
> isn't related to setting base information on the objfile or reading
> dwarf can be removed.
>
> The unfortunate part of this removal is that XCOFF minimal symbols are
> encoded in stabs, so if an inferior has not been compiled with dwarf
> debuginfo, GDB will only be able to do assembly-level debugging. Due to
> this, the xcoff reader now emits a warning if no dwarf is read, saying:
> "No usable debug information found". This change would also add a lot of
> regressions to to AIX, so the gdb_compile proc has been changed to not
> work when a test tries to compile a test with nodebug.
>
> As a sidenote, gdb-stabs.h can just be removed from rs6000-aix-nat, as
> none of the structs or macros defined in the header are used in the nat
> file, so that is an unnecessary include.
>
> This commit introduces some known regressions when testing GDB in AIX
> systems. The main ones are:
> * inferior function calls now crash with a corrupted stack. This seems
> to be some fault of dwarf in explaining how to correctly set the frame
> for a function.
> * fortran tests can't runto_main: the fortran compiler does not add any
> symbol for MAIN__ in the dwarf information, only in stabs, so the
> fortran_runto_main proc can't set the breakpoint correctly.
> * When dealing with c++ class methods, there are cases when we fail to
> properly recognize a method call as a new function.
> * When dealing with c++ virtual inheritance, GDB has issues finding a
> derived class's members when it has been downcast to a base class.

A colleague reported this build failure after this commit:

CXX gdb.o
../../../binutils-gdb/gdb/xcoffread.c: In function 'void enter_line_range(subfile*, unsigned int, unsigned int, CORE_ADDR, CORE_ADDR, unsigned int*)':
../../../binutils-gdb/gdb/xcoffread.c:573:44: error: 'this' pointer is null [-Werror=nonnull]
573 | addr += objfile->text_section_offset ();
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
In file included from ../../../binutils-gdb/gdb/xcoffread.c:43:
../../../binutils-gdb/gdb/objfiles.h:512:13: note: in a call to non-static member function 'CORE_ADDR objfile::text_section_offset() const'
512 | CORE_ADDR text_section_offset () const
| ^~~~~~~~~~~~~~~~~~~
../../../binutils-gdb/gdb/xcoffread.c:579:63: error: 'this' pointer is null [-Werror=nonnull]
579 | - objfile->text_section_offset ());
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
../../../binutils-gdb/gdb/objfiles.h:512:13: note: in a call to non-static member function 'CORE_ADDR objfile::text_section_offset() const'
512 | CORE_ADDR text_section_offset () const
| ^~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors

This was building GDB on current Fedora rawhide, with
gcc-15.2.1-2.fc44.x86_64.

The compiler is being pretty insightful here. OBJFILE is initialised
within the function like this:

struct objfile *objfile = this_symtab_objfile;

And THIS_SYMTAB_OBJFILE is a static variable within this file that is
initialised to NULL.

After this commit, there is now no longer any way that
THIS_SYMTAB_OBJFILE can be set to a non-null value, so the above
warning/error seems legit.

This opens a bigger question (in my mind). Either the code in
xcoffread.c that depends on THIS_SYMTAB_OBJFILE needs deleting, or some
parts of this commit need restoring.

I've not had a chance to look into this yet, so don't currently have an
opinion either way.

Thanks,
Andrew