From: Guinevere Larsen <guinevere@redhat.com>
To: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Follow up to stabs deprecation - AIX regressions
Date: Thu, 13 Feb 2025 09:25:44 -0300 [thread overview]
Message-ID: <b3715f9f-3440-40b0-b2be-18fcd064bf26@redhat.com> (raw)
Hi all,
I've been working on the removal of stabs ahead of schedule, and testing
what I could test.
I noticed that the debug experience in AIX is severely affected by the
removal of stabs. The most noticeable things I've seen is:
* DWARF reading can sometimes fail in AIX. Currently, reading dwarf for
xcoff inferiors is called on it's own, with no warning if dwarf fails
(which probably makes sense, considering the default format in aix is
still stabs). I added a warning when failing to read dwarf and noticed
it being triggered on inferiors compiled with -gdwarf
* DWARF reading is also outdated. the dwarf2_xcoff_names struct is
missing 4 section names based on IBM docs[1], the one I remember is
.dwarnge.
* Dealing with C++ classes has 2 obvious issues: when a pointer of an
inherited class is downcast, GDB is unable to find members of the
original type (that should be accessible), and GDB doesn't quite
understand class methods as functions - step will skip method calls -
plus a few more issues ado with understanding inheritance, as tested in
gdb.cp/casts.exp
* Fortran tests can't runto_main. This seems to be a compiler issue, as
the fortran_runto_main identifies the main function as MAIN__, but
examining the generated dwarf there is no symbol for that.
* You just can't call inferior functions by hand. Most of the time, it
gets a segfault with a corrupted stack. Considering that this used to
work when reading stabs, it feels like the dwarf isn't properly
explaining something about the frame that GDB uses to create dummy
frames for the hand call, and it looks like it'd require a lot of system
knowledge to fix
I haven't looked too in-depth into all failures, this is the large-scale
patterns and my best attempt at explaining why things are failing how
they are. Considering the state that AIX was in before I started testing
it (less than 40k passes, and simply compiling with dwarf we can move up
to 74.5k), and considering that the current maintainer of AIX is Kevin -
who from our conversations remembers very little of how xcoff and aix
work - I don't think this would warrant delaying removing stabs, but I
think we should be aware of it so that if folks are using AIX, or
interested in fixing it, they have until the release of GDB 18 to get
the regressions under control.
[1]
https://www.ibm.com/docs/en/aix/7.3?topic=formats-xcoff-object-file-format
--
Cheers,
Guinevere Larsen
She/Her/Hers
next reply other threads:[~2025-02-13 12:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-13 12:25 Guinevere Larsen [this message]
2025-02-13 16:48 ` Kevin Buettner
2025-02-13 17:21 ` Guinevere Larsen
2025-02-13 17:43 ` Kevin Buettner
2025-02-13 17:58 ` Guinevere Larsen
2025-02-13 20:21 ` Simon Marchi
2025-02-14 17:53 ` Guinevere Larsen
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=b3715f9f-3440-40b0-b2be-18fcd064bf26@redhat.com \
--to=guinevere@redhat.com \
--cc=gdb-patches@sourceware.org \
/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