From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55220 invoked by alias); 28 Sep 2017 14:37:15 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 54137 invoked by uid 89); 28 Sep 2017 14:37:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.8 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=loan, ressources, reluctant, act 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; Thu, 28 Sep 2017 14:37:12 +0000 Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id C5B7ED98; Thu, 28 Sep 2017 16:37:09 +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 QavUm5VOXI-v; Thu, 28 Sep 2017 16:37:07 +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 45F13D96; Thu, 28 Sep 2017 16:37:07 +0200 (CEST) Received: (from ro@localhost) by lokon.CeBiTec.Uni-Bielefeld.DE (8.15.2+Sun/8.15.2/Submit) id v8SEb6uQ013513; Thu, 28 Sep 2017 16:37:06 +0200 (MEST) From: Rainer Orth To: Pedro Alves Cc: Wei-min Pan , gdb-patches@sourceware.org Subject: Re: Fix gdb 8.1 Solaris/SPARC compilation (PR build/22206) References: <9f2fc29a-18a2-76c8-8e88-b7694ffe9f38@oracle.com> <1c43ef2e-00cb-5ede-de6e-1e25fe7e09cd@redhat.com> Date: Thu, 28 Sep 2017 14:37:00 -0000 In-Reply-To: <1c43ef2e-00cb-5ede-de6e-1e25fe7e09cd@redhat.com> (Pedro Alves's message of "Thu, 28 Sep 2017 15:19:47 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017-09/txt/msg00865.txt.bz2 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 -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University