Re: contributing the RISC-V linux native port

> 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/<username>/<branch-name>".

-- 
Joel