From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id EFF7F3858413 for ; Wed, 15 Sep 2021 06:26:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EFF7F3858413 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id BDF07221C0; Wed, 15 Sep 2021 06:26:32 +0000 (UTC) Received: from murzim.suse.de (murzim.suse.de [10.160.4.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 96F18A3B90; Wed, 15 Sep 2021 06:26:32 +0000 (UTC) Date: Wed, 15 Sep 2021 08:26:32 +0200 (CEST) From: Richard Biener To: John David Anglin cc: Jeff Law , 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 In-Reply-To: <04bf2ae0-dd68-c5d8-92ee-6ea4a0c12c26@bell.net> Message-ID: References: <66161527-98n2-3060-49ss-67oro67381nq@fhfr.qr> <7c622dea-ac79-869e-23a0-7d363ec50947@gmail.com> <2f5fdfff-d7dd-c8ab-b384-17cc4c5c0c12@gmail.com> <04bf2ae0-dd68-c5d8-92ee-6ea4a0c12c26@bell.net> MIME-Version: 1.0 X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2021 06:26:35 -0000 On Mon, 13 Sep 2021, 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. Do you think it's worth keeping the 32bit pa hpux targets for another release but guarded with --enable-obsolete or can we remove those configurations right away? In the current setting configurations that do not support DWARF will get no debug info with -g (with a warning that this happens) and STABS debug info with -gstabs (with a warning about its deprecation). That might not be the final outcome for GCC 12 but it's the minimal change I'm working towards. > 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. The 64bit pa configs seem to support DWARF so they are fine, correct, it's only 32bit hpux configs that we'll leave behind. Richard. > > > >> > >> There is some support for hpux10/11 in qemu but it takes a lot of work to provide the build infrastructure needed for gcc. > > I would think so. > Recently had to move my build infrastructure to a "new" machine, so I'm fully aware that it's not easy. > > > >> > >> 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.