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

[Andrew Burgess <aburgess@redhat.com>]

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