From: Guinevere Larsen <guinevere@redhat.com>
To: Simon Marchi <simark@simark.ca>, Kevin Buettner <kevinb@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: Follow up to stabs deprecation - AIX regressions
Date: Fri, 14 Feb 2025 14:53:26 -0300 [thread overview]
Message-ID: <7810dcf9-5f59-4fad-9352-e9d5dcb98f10@redhat.com> (raw)
In-Reply-To: <35754735-34f5-4aca-99e4-3862f8cde5b9@simark.ca>
On 2/13/25 5:21 PM, Simon Marchi wrote:
>
> On 2025-02-13 12:58, Guinevere Larsen wrote:
>> On 2/13/25 2:43 PM, Kevin Buettner wrote:
>>> On Thu, 13 Feb 2025 14:21:01 -0300
>>> Guinevere Larsen <guinevere@redhat.com> wrote:
>>>
>>>> On 2/13/25 1:48 PM, Kevin Buettner wrote:
>>>>> On Thu, 13 Feb 2025 09:25:44 -0300
>>>>> Guinevere Larsen <guinevere@redhat.com> wrote:
>>>>>
>>>>>> * 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
>>>>> I assume that you mean that stabs is the default when compiling with
>>>>> gcc. Is stabs still also the default format for XLC (IBM Open XL C/C++) ?
>>>> Yes, sorry, I meant gcc. The compile farm had versions 10 and 12, both
>>>> with the same behavior.
>>>>
>>>> I don't think the compile farm has XLC compilers available for testing,
>>>> or if they do I don't know how to use it, so I couldn't tell you...
>>> I think it'd be good to find out XLC's preferred debug format. If it
>>> uses/prefers DWARF, that'd be a good argument for gcc (on AIX)
>>> switching to DWARF for it's preferred format too.
>>>
>>> Kevin
>>>
>> I just looked over at the GCC releases, and the GCC12 changelog says the following:
>>
>> * *STABS:* Support for emitting the STABS debugging format is deprecated and will be removed in the next release. All ports now default to emit DWARF (version 2 or later) debugging info or are obsoleted.
>>
>> Since the default is supposed to have changed *in* gcc 12 - which is the version that AIX has - or the port be obsolete, it looks to me like that gcc on AIX is obsoleted...
>>
>> In other words, gcc already knows it should change but seems to have given up on AIX?
> Given this commit (present in gcc 11):
>
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=56b5d13e27891ed1caec07826a07bb2e0621f914
>
> I would expect gcc 12 to produce DWARF by default, I'm not sure why you
> don't see that.
>
> Simon
>
This is kind of weird...
This is a bit of a side diversion, though. The original thing Kevin
pointed out was whether GDB not reporting that DWARF reading failed was
related to stabs being the default.
I just double checked, and I don't think it is. elfread reads dwarf in
an if condition, but doesn't do anything with the result (no matter if
it is positive or negative). coffread does the same
I think the idea is that maybe the objfile being read may have not been
compiled with debug symbols in the first place, so warning about it is
redundant, especially considering that for now, all supported objfiles
will have at least minsyms available. That will change with removing
stabs in xcoff, which is why I highlighted that it can fail even with
existing dwarf in the inferior. It not being reported is the default,
but is why this has gone unnoticed.
--
Cheers,
Guinevere Larsen
She/Her/Hers
prev parent reply other threads:[~2025-02-14 17:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-13 12:25 Guinevere Larsen
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 [this message]
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=7810dcf9-5f59-4fad-9352-e9d5dcb98f10@redhat.com \
--to=guinevere@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=kevinb@redhat.com \
--cc=simark@simark.ca \
/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