public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <jeffreyalaw@gmail.com>
To: John David Anglin <dave.anglin@bell.net>,
	Richard Biener <rguenther@suse.de>
Cc: gcc-patches@gcc.gnu.org, schwab@linux-m68k.org, ni1d@arrl.net
Subject: Re: [PATCH][v2] Always default to DWARF2_DEBUG if not specified, warn about deprecated STABS
Date: Mon, 13 Sep 2021 09:52:02 -0600	[thread overview]
Message-ID: <a879c015-3f7c-3b0d-7081-be12396cda29@gmail.com> (raw)
In-Reply-To: <04bf2ae0-dd68-c5d8-92ee-6ea4a0c12c26@bell.net>



On 9/13/2021 9:44 AM, John David Anglin wrote:
> On 2021-09-13 11:05 a.m., Jeff Law wrote:
>>
>> On 9/13/2021 8:58 AM, John David Anglin wrote:
>>> On 2021-09-13 9:53 a.m., Jeff Law wrote:
>>>>> It is in fact also hpux11*, thus all 32bit pa configs that do not support
>>>>> DWARF (for whatever reasons).
>>>> We used embedded stabs for SOM (the native format for 32bit PA). SOM is a variant of COFF and could easily support dwarf I would think since
>>>> it had support for fairly arbitrary sections.  Hell, it was already supporting embedded stabs as well as HP's proprietary debugging format.
>>>>
>>>> But I'd consider 32bit SOM on hpux11 dead too :-)
>>> I don't disagree but 32bit SOM still builds on hpux11:
>>> https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/718130.html
>>>
>>> Suspect the change will cause a lot of warnings.
>> It might, but with stabs going away something needs to be done with these legacy systems.  Either they need to move into the modern world,
>> deal with the diagnostic  or get dropped.
> I believe the 32-bit SOM target should be deprecated.  I'm the only one maintaining it and I had some health issues earlier this year.
> The current versions should suffice for several years.
Seems quite reasonable.

>
> My main interest is the Debian parisc-linux target.  It's fully up to date and thousands of packages are available.  Most kernels are 64-bit.
> Since there's no 64-bit runtime for Linux, we still need the 64-bit hpux target for 64-bit compile testing.
Agreed.  Given that the 32bit linux and 64bit hpux targets both use ELF 
+ dwarf, they're not in danger of significant fallout from the stabs 
removal effort.
>
>>> DWARF isn't supported because we lack named sections.  That could be worked around
>>> but probably the gdb versions that work on 32-bit hpux11 wouldn't support DWARF.
>> I'd be a bit surprised if that were true.  dwarf support has been around a long long time in GDB.  Hell, it was around when I did the original
>> 64bit PA work back in the 90s.
> There's a chance it might work with the right section names.  However dwarf 5 wouldn't be supported.  That's an issue that I noticed recently.
Yea, without a modern gdb, 32bit SOM would be stuck back in the dwarf2 
era.  But even that's better than embedded stabs.

jeff

  reply	other threads:[~2021-09-13 15:52 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-13  7:31 Richard Biener
2021-09-13 13:24 ` Jeff Law
2021-09-13 13:47   ` Richard Biener
2021-09-13 13:53     ` Jeff Law
2021-09-13 14:58       ` John David Anglin
2021-09-13 15:05         ` Jeff Law
2021-09-13 15:44           ` John David Anglin
2021-09-13 15:52             ` Jeff Law [this message]
2021-09-15  6:26             ` Richard Biener
2021-09-15 13:27               ` John David Anglin
2021-09-15 14:06                 ` Richard Biener
2021-09-15 15:55                   ` John David Anglin
2021-09-15 17:18                     ` Koning, Paul
2021-09-13 16:52 ` Koning, Paul
2021-09-13 19:06   ` Jeff Law
2021-09-15 20:23 ` Koning, Paul
2021-09-16  7:41   ` Richard Biener
2021-09-16 15:05     ` Jeff Law
2021-09-16 16:46       ` Koning, Paul

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=a879c015-3f7c-3b0d-7081-be12396cda29@gmail.com \
    --to=jeffreyalaw@gmail.com \
    --cc=dave.anglin@bell.net \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=ni1d@arrl.net \
    --cc=rguenther@suse.de \
    --cc=schwab@linux-m68k.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).