From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5004 invoked by alias); 7 Aug 2018 13:01:28 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 4989 invoked by uid 89); 7 Aug 2018 13:01:27 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=username, personal X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 07 Aug 2018 13:01:26 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 7CEDF117022; Tue, 7 Aug 2018 09:01:24 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DSGtzQ0deXQd; Tue, 7 Aug 2018 09:01:24 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 4BC8C117018; Tue, 7 Aug 2018 09:01:24 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 794DE82C46; Tue, 7 Aug 2018 06:01:22 -0700 (PDT) Date: Tue, 07 Aug 2018 13:01:00 -0000 From: Joel Brobecker To: Jim Wilson Cc: gdb@sourceware.org Subject: Re: contributing the RISC-V linux native port Message-ID: <20180807130122.GI2432@adacore.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-SW-Source: 2018-08/txt/msg00018.txt.bz2 > There are some obvious things broken. 32-bit float values in 64-bit > FP registers aren't printed properly because they are NaN-boxed, and > gdb doesn't know about that yet. I don't have support for signal > handler frames yet. I only have integer register support for core > files. I haven't tried to implement watchpoints yet. There are a lot > of thread failures, 358 in gdb.thread, and apparently some in gdb.mi > also, but there is a glibc patch from Andreas Schwab that I hope fixes > some of them. Most of the rest of the failures I haven't categorized > yet. > > Anyways, I'm wondering how much more work I need to do out of tree > before I can try submitting my work. I don't think we have a specific guideline for this; my opinion is that you don't have to wait for something to be perfect before you can submit it for inclusion. What you want to ask yourself is, assuming your patch is improving things already (and therefore being helpful to you and probably others), does it have a cost elsewhere? For instance, will it make harder to fix something later, or does it break something else, etc? If, as is often the case, you find that the code is self contained and doesn't hurt anything else, why not submit it already, so others can benefit from it? As long as the code passes the coding standards, I don't see how it could hurt. > Also, I'm wondering about policy on branches in the gdb tree. Maybe > it would make sense to move my work into a branch in the FSF gdb tree. > I have my own github tree at the moment where I am doing work which is > working fine for me, but it isn't easy for other people to find it. Users can have personal branches under "users//". -- Joel