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

[Guinevere Larsen <guinevere@redhat.com>]

On 11/7/25 7:46 AM, Andrew Burgess wrote:
> 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
>
Simon also raised this with me yesterday on IRC and sent this email to 
the AIX folks: 
https://inbox.sourceware.org/gdb-patches/b3afe6c6-8dc3-49be-8fca-43d0b3bddd56@polymtl.ca/T/#u

I'd prefer to keep discussion to this on that thread, as it is more 
likely to be caught by the folk who are most likely to know what's going 
on. I'll take a look at this failure today either way and see if there 
is an easy out that doesn't require much AIX knowledge

-- 
Cheers,
Guinevere Larsen
It/she