Message ID | yddfub9x0rp.fsf@CeBiTec.Uni-Bielefeld.DE |
---|---|
State | New, archived |
Headers |
Received: (qmail 90112 invoked by alias); 26 Sep 2017 09:33:23 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 90068 invoked by uid 89); 26 Sep 2017 09:33:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-19.3 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_2, GIT_PATCH_3, KAM_LAZY_DOMAIN_SECURITY, RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=adi, int=e2, D*Uni-Bielefeld.DE, rocebitecunibielefeldde?= X-HELO: smtp.CeBiTec.Uni-Bielefeld.DE Received: from smtp.CeBiTec.Uni-Bielefeld.DE (HELO smtp.CeBiTec.Uni-Bielefeld.DE) (129.70.160.84) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Sep 2017 09:33:20 +0000 Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 9B4D51A2; Tue, 26 Sep 2017 11:33:18 +0200 (CEST) Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (malfoy.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sJ0Aq+blQnRd; Tue, 26 Sep 2017 11:33:14 +0200 (CEST) Received: from lokon.CeBiTec.Uni-Bielefeld.DE (lokon.CeBiTec.Uni-Bielefeld.DE [129.70.161.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPS id C78A519E; Tue, 26 Sep 2017 11:33:14 +0200 (CEST) Received: (from ro@localhost) by lokon.CeBiTec.Uni-Bielefeld.DE (8.15.2+Sun/8.15.2/Submit) id v8Q9XEWF022415; Tue, 26 Sep 2017 11:33:14 +0200 (MEST) From: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> To: gdb-patches@sourceware.org Cc: Weimin Pan <weimin.pan@oracle.com> Subject: Fix gdb 8.1 Solaris/SPARC compilation (PR build/22206) Date: Tue, 26 Sep 2017 11:33:14 +0200 Message-ID: <yddfub9x0rp.fsf@CeBiTec.Uni-Bielefeld.DE> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (usg-unix-v) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" |
Commit Message
Rainer Orth
Sept. 26, 2017, 9:33 a.m. UTC
When testing my Solaris < 10 removal patch on Solaris/SPARC, I found that gdb mainline is currently broken there due to the recent SPARC M7 ADI patches: /vol/src/gnu/gdb/gdb/local/gdb/sparc64-tdep.c:1876:0: error: "PSR_ICC" redefined [-Werror] #define PSR_ICC 0x00f00000 ^ In file included from /usr/include/v7/sys/privregs.h:24:0, from /usr/include/sys/regset.h:420, from /usr/include/sys/ucontext.h:21, from /usr/include/sys/signal.h:231, from /usr/include/sys/procset.h:23, from /usr/include/sys/wait.h:25, from /usr/include/stdlib.h:21, from build-gnulib/import/stdlib.h:36, from /vol/src/gnu/gdb/gdb/local/gdb/common/common-defs.h:53, from /vol/src/gnu/gdb/gdb/local/gdb/defs.h:28, from /vol/src/gnu/gdb/gdb/local/gdb/sparc64-tdep.c:20: /usr/include/v7/sys/psr.h:35:0: note: this is the location of the previous definition #define PSR_ICC 0x00F00000 /* integer condition codes */ ^ /vol/src/gnu/gdb/gdb/local/gdb/sparc64-tdep.c:1878:0: error: "PSR_IMPL" redefined [-Werror] #define PSR_IMPL 0xf0000000 ^ In file included from /usr/include/v7/sys/privregs.h:24:0, from /usr/include/sys/regset.h:420, from /usr/include/sys/ucontext.h:21, from /usr/include/sys/signal.h:231, from /usr/include/sys/procset.h:23, from /usr/include/sys/wait.h:25, from /usr/include/stdlib.h:21, from build-gnulib/import/stdlib.h:36, from /vol/src/gnu/gdb/gdb/local/gdb/common/common-defs.h:53, from /vol/src/gnu/gdb/gdb/local/gdb/defs.h:28, from /vol/src/gnu/gdb/gdb/local/gdb/sparc64-tdep.c:20: /usr/include/v7/sys/psr.h:41:0: note: this is the location of the previous definition #define PSR_IMPL 0xF0000000 /* implementation */ ^ Comparing Solaris 11.4 <v7/sys/psr.h> and sparc64-tdep.c, there are more inconsistencies: <v7/sys/psr.h>: #define PSR_S 0x00000080 /* supervisor mode */ #define PSR_ICC 0x00F00000 /* integer condition codes */ #define PSR_VER 0x0F000000 /* mask version */ #define PSR_IMPL 0xF0000000 /* implementation */ #define PSR_RSV 0x000FC000 /* reserved */ sparc64-tdep.c: #define PSR_S 0x00000080 #define PSR_ICC 0x00f00000 #define PSR_VERS 0x0f000000 #define PSR_IMPL 0xf0000000 #define PSR_V8PLUS 0xff000000 #define PSR_XCC 0x000f0000 Apart from the capitalization differences that trip g++, the names differ (PSR_VER vs. PSR_VERS), PSR_XCC is included in Solaris' PSR_RSV, and there's no PSR_V8PLUS on Solaris either. /vol/src/gnu/gdb/gdb/local/gdb/sparc64-tdep.c: In function ‘int adi_tag_fd()’: /vol/src/gnu/gdb/gdb/local/gdb/sparc64-tdep.c:296:63: error: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘pid_t {aka long int}’ [-Werror=format=] snprintf (cl_name, sizeof(cl_name), "/proc/%d/adi/tags", pid); ^ /vol/src/gnu/gdb/gdb/local/gdb/sparc64-tdep.c: In function ‘bool adi_is_addr_mapped(CORE_ADDR, std::size_t)’: /vol/src/gnu/gdb/gdb/local/gdb/sparc64-tdep.c:314:64: error: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘pid_t {aka long int}’ [-Werror=format=] snprintf (filename, sizeof filename, "/proc/%d/adi/maps", pid); ^ You cannot always print a pid_t, which can be either int or long on Solaris, as an int. Obviously, the ADI patch which modifies code shared between all SPARC targets, hasn't been tested on anything but Linux/SPARC. The patch below includes the minimal fixes necessary to unbreak the Solaris/SPARC build. However, as detailed in the PR, there's more breakage here: apart from not bothering to implement ADI support on Solaris, the code contains several more changes to shared/common SPARC code that are simply wrong on anything but Linux/SPARC. The patch was tested on sparcv9-sun-solaris2.10 and sparcv9-sun-solaris2.11.4 (build and gdb/gdb gdb/gdb smoke test only). Ok for mainline? Rainer
Comments
On 09/26/2017 10:33 AM, Rainer Orth wrote: > Apart from the capitalization differences that trip g++, the names > differ (PSR_VER vs. PSR_VERS), PSR_XCC is included in Solaris' PSR_RSV, > and there's no PSR_V8PLUS on Solaris either. What you've done is fine with me to unbreak the build. Though I'd prefer if we renamed those to avoid ever relying on host symbols, anywhere. Like: - #define PSR_S ... + #define SPARC64_PSR_S ... etc. > > /vol/src/gnu/gdb/gdb/local/gdb/sparc64-tdep.c: In function ‘int adi_tag_fd()’: > /vol/src/gnu/gdb/gdb/local/gdb/sparc64-tdep.c:296:63: error: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘pid_t {aka long int}’ [-Werror=format=] > snprintf (cl_name, sizeof(cl_name), "/proc/%d/adi/tags", pid); > ^ > /vol/src/gnu/gdb/gdb/local/gdb/sparc64-tdep.c: In function ‘bool adi_is_addr_mapped(CORE_ADDR, std::size_t)’: > /vol/src/gnu/gdb/gdb/local/gdb/sparc64-tdep.c:314:64: error: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘pid_t {aka long int}’ [-Werror=format=] > snprintf (filename, sizeof filename, "/proc/%d/adi/maps", pid); > ^ > > You cannot always print a pid_t, which can be either int or long on > Solaris, as an int. > > Obviously, the ADI patch which modifies code shared between all SPARC > targets, hasn't been tested on anything but Linux/SPARC. > > The patch below includes the minimal fixes necessary to unbreak the > Solaris/SPARC build. > > However, as detailed in the PR, there's more breakage here: apart from > not bothering to implement ADI support on Solaris, the code contains > several more changes to shared/common SPARC code that are simply wrong > on anything but Linux/SPARC. > > The patch was tested on sparcv9-sun-solaris2.10 and > sparcv9-sun-solaris2.11.4 (build and gdb/gdb gdb/gdb smoke test only). > > Ok for mainline? OK. Thanks, Pedro Alves
Hi Pedro, > On 09/26/2017 10:33 AM, Rainer Orth wrote: > >> Apart from the capitalization differences that trip g++, the names >> differ (PSR_VER vs. PSR_VERS), PSR_XCC is included in Solaris' PSR_RSV, >> and there's no PSR_V8PLUS on Solaris either. > > What you've done is fine with me to unbreak the build. Though > I'd prefer if we renamed those to avoid ever relying on host > symbols, anywhere. Like: > > - #define PSR_S ... > + #define SPARC64_PSR_S ... > > etc. agreed. That's probably best done when figuring out how to properly separate target-dependent and independent parts of ADI support. Rainer
On 9/26/2017 6:02 AM, Rainer Orth wrote: > Hi Pedro, > >> On 09/26/2017 10:33 AM, Rainer Orth wrote: >> >>> Apart from the capitalization differences that trip g++, the names >>> differ (PSR_VER vs. PSR_VERS), PSR_XCC is included in Solaris' PSR_RSV, >>> and there's no PSR_V8PLUS on Solaris either. >> What you've done is fine with me to unbreak the build. Though >> I'd prefer if we renamed those to avoid ever relying on host >> symbols, anywhere. Like: >> >> - #define PSR_S ... >> + #define SPARC64_PSR_S ... >> >> etc. > agreed. That's probably best done when figuring out how to properly > separate target-dependent and independent parts of ADI support. > > Rainer > Macros PSR_ICC/PSR_IMPL are not parts of ADI and were added to sparc64-tdep.c long before the Linux ADI project. Still trying to figure out why these two macros, pulled from /usr/include/v7/sys/psr.h, are causing problems now.
Hi Wei-min, > On 9/26/2017 6:02 AM, Rainer Orth wrote: >> Hi Pedro, >> >>> On 09/26/2017 10:33 AM, Rainer Orth wrote: >>> >>>> Apart from the capitalization differences that trip g++, the names >>>> differ (PSR_VER vs. PSR_VERS), PSR_XCC is included in Solaris' PSR_RSV, >>>> and there's no PSR_V8PLUS on Solaris either. >>> What you've done is fine with me to unbreak the build. Though >>> I'd prefer if we renamed those to avoid ever relying on host >>> symbols, anywhere. Like: >>> >>> - #define PSR_S ... >>> + #define SPARC64_PSR_S ... >>> >>> etc. >> agreed. That's probably best done when figuring out how to properly >> separate target-dependent and independent parts of ADI support. >> >> Rainer >> > > Macros PSR_ICC/PSR_IMPL are not parts of ADI and were added to > sparc64-tdep.c > long before the Linux ADI project. Still trying to figure out why these two > macros, > pulled from /usr/include/v7/sys/psr.h, are causing problems now. I suspect there were changes to gdb/defs.h, gdb/common/common-defs.h or gnulib that ultimately dragged that file in post gdb-8.1. Seems I've been barking up the wrong tree for this one, sorry. Even so, the other problems with the ADI implemention mentioned both in the patch submission and the PR are certainly new. Rainer
Hi Rainer, On 9/27/2017 2:16 AM, Rainer Orth wrote: > Hi Wei-min, > >> On 9/26/2017 6:02 AM, Rainer Orth wrote: >>> Hi Pedro, >>> >>>> On 09/26/2017 10:33 AM, Rainer Orth wrote: >>>> >>>>> Apart from the capitalization differences that trip g++, the names >>>>> differ (PSR_VER vs. PSR_VERS), PSR_XCC is included in Solaris' PSR_RSV, >>>>> and there's no PSR_V8PLUS on Solaris either. >>>> What you've done is fine with me to unbreak the build. Though >>>> I'd prefer if we renamed those to avoid ever relying on host >>>> symbols, anywhere. Like: >>>> >>>> - #define PSR_S ... >>>> + #define SPARC64_PSR_S ... >>>> >>>> etc. >>> agreed. That's probably best done when figuring out how to properly >>> separate target-dependent and independent parts of ADI support. >>> >>> Rainer >>> >> Macros PSR_ICC/PSR_IMPL are not parts of ADI and were added to >> sparc64-tdep.c >> long before the Linux ADI project. Still trying to figure out why these two >> macros, >> pulled from /usr/include/v7/sys/psr.h, are causing problems now. > I suspect there were changes to gdb/defs.h, gdb/common/common-defs.h or > gnulib that ultimately dragged that file in post gdb-8.1. Seems I've > been barking up the wrong tree for this one, sorry. > > Even so, the other problems with the ADI implemention mentioned both in > the patch submission and the PR are certainly new. > > Rainer > Thanks for tracking down the marco problem. As for the issues you raised on gdb ADI support for Solaris/SPARC in the bug report, it's never intended to add that support for Solaris. While that Solaris provided a totally different ADI API was a factor, for example, Linux made the information of ADI block size available in the ELF aux record, one needed to make a syscall on Solaris to get that piece of information, it's certainly doable. It was never planned, however, and most likely will never be.
Hi Wei-min, > As for the issues you raised on gdb ADI support for Solaris/SPARC in the > bug report, > it's never intended to add that support for Solaris. While that Solaris > provided a totally > different ADI API was a factor, for example, Linux made the information of > ADI block > size available in the ELF aux record, one needed to make a syscall on > Solaris to get that > piece of information, it's certainly doable. It was never planned, > however, and most likely > will never be. this is extremely unfortunate, Oracle adding ADI support for one OS, but not for its own ;-( However, what's worse is the way in which ADI support was added: when you add code to a file shared between different OSes like sparc64-tdep.c, it's your responsibility to make sure that this code at least doesn't break other SPARC targets. Given how much of the code there isn't actually shared (and not sharable, it seems), the approach you've take seems wrong to me: it should have been properly factored between shared (sparc64-tdep.c) and os-private (e.g. sparc64-linux-tdep.c) files to avoid such breakage in the first place. Rainer
On 09/28/2017 01:40 PM, Rainer Orth wrote: > Hi Wei-min, > >> As for the issues you raised on gdb ADI support for Solaris/SPARC in the >> bug report, >> it's never intended to add that support for Solaris. While that Solaris >> provided a totally >> different ADI API was a factor, for example, Linux made the information of >> ADI block >> size available in the ELF aux record, one needed to make a syscall on >> Solaris to get that >> piece of information, it's certainly doable. It was never planned, >> however, and most likely >> will never be. > > this is extremely unfortunate, Oracle adding ADI support for one OS, but > not for its own ;-( > > However, what's worse is the way in which ADI support was added: when > you add code to a file shared between different OSes like > sparc64-tdep.c, it's your responsibility to make sure that this code at > least doesn't break other SPARC targets. Given how much of the code > there isn't actually shared (and not sharable, it seems), the approach > you've take seems wrong to me: it should have been properly factored > between shared (sparc64-tdep.c) and os-private > (e.g. sparc64-linux-tdep.c) files to avoid such breakage in the first > place. To be fair, that is the sort of issue that should have been pointed out in review. When I pushed for moving the ADI support out of the nat files and into tdep files for cross debugging, I don't think I even remembered Solaris was a thing... Not that I have anything against Solaris, to be clear. It just didn't cross my mind. To me, this indicates a few things: - It's great that the Solaris port is again seeing activity, and we should strive to make sure that SPARC changes consider it. - But also someone needs to continually keep an eye on Solaris lest it ends up forgotten and broken again. We need an official Solaris port maintainer. Any takers? :-) - It'd be desirable to have a SPARC Solaris machine build slave in the GDB buildbot, so that we can offload part of the work to bots. I wonder whether Oracle can help with this? Might be difficult with the whole Solaris situation... Thanks, Pedro Alves
Hi Pedro, >> this is extremely unfortunate, Oracle adding ADI support for one OS, but >> not for its own ;-( >> >> However, what's worse is the way in which ADI support was added: when >> you add code to a file shared between different OSes like >> sparc64-tdep.c, it's your responsibility to make sure that this code at >> least doesn't break other SPARC targets. Given how much of the code >> there isn't actually shared (and not sharable, it seems), the approach >> you've take seems wrong to me: it should have been properly factored >> between shared (sparc64-tdep.c) and os-private >> (e.g. sparc64-linux-tdep.c) files to avoid such breakage in the first >> place. > > To be fair, that is the sort of issue that should have been pointed out > in review. When I pushed for moving the ADI support out of the nat > files and into tdep files for cross debugging, I don't think I even > remembered Solaris was a thing... Not that I have anything against > Solaris, to be clear. It just didn't cross my mind. understandable: it hasn't been exactly prominent until very recently... > To me, this indicates a few things: > > - It's great that the Solaris port is again seeing activity, and > we should strive to make sure that SPARC changes consider it. > > - But also someone needs to continually keep an eye on Solaris > lest it ends up forgotten and broken again. We need an official > Solaris port maintainer. Any takers? :-) TBH, I'm a bit reluctant to take the position. I've already too much on my plate and am unsure if I can follow gdb development in any useful way. Right now, it's just testing gdb either when releases approach or when major changes go in. > - It'd be desirable to have a SPARC Solaris machine build slave > in the GDB buildbot, so that we can offload part of the work to > bots. I wonder whether Oracle can help with this? Might be > difficult with the whole Solaris situation... Certainly from Oracle, but fortunately they provided me with a Netra S7-2 as a long-term loan for my GCC work a few months ago. I've even set up a Solaris 11.3 zone to act as a build zone for Go and eventually other FOSS developers to test on, and am considering to add it to the GCC build farm if appropriate terms can be worked out. That zone would be a natural candidate for a GDB build slave provided that doesn't take too many ressources. Rainer
# HG changeset patch # Parent 5123ae285cd10f18efd6d5db4a75bc4989514ef1 Fix gdb 8.1 Solaris/SPARC compilation (PR build/22206) diff --git a/gdb/sparc64-tdep.c b/gdb/sparc64-tdep.c --- a/gdb/sparc64-tdep.c +++ b/gdb/sparc64-tdep.c @@ -293,7 +293,7 @@ adi_tag_fd (void) return proc->stat.tag_fd; char cl_name[MAX_PROC_NAME_SIZE]; - snprintf (cl_name, sizeof(cl_name), "/proc/%d/adi/tags", pid); + snprintf (cl_name, sizeof(cl_name), "/proc/%ld/adi/tags", (long) pid); int target_errno; proc->stat.tag_fd = target_fileio_open (NULL, cl_name, O_RDWR|O_EXCL, 0, &target_errno); @@ -311,7 +311,7 @@ adi_is_addr_mapped (CORE_ADDR vaddr, siz size_t i = 0; pid_t pid = ptid_get_pid (inferior_ptid); - snprintf (filename, sizeof filename, "/proc/%d/adi/maps", pid); + snprintf (filename, sizeof filename, "/proc/%ld/adi/maps", (long) pid); char *data = target_fileio_read_stralloc (NULL, filename); if (data) { @@ -1873,9 +1873,13 @@ sparc64_init_abi (struct gdbarch_info in #define TSTATE_XCC 0x000000f000000000ULL #define PSR_S 0x00000080 +#ifndef PSR_ICC #define PSR_ICC 0x00f00000 +#endif #define PSR_VERS 0x0f000000 +#ifndef PSR_IMPL #define PSR_IMPL 0xf0000000 +#endif #define PSR_V8PLUS 0xff000000 #define PSR_XCC 0x000f0000