contributing the RISC-V linux native port

contributing the RISC-V linux native port

[Jim Wilson]

I'm wondering about what level of functionality I need to reach before
it would be reasonable to try to submit my gdb port.  I have a lot of
basic features working, setting breakpoints, run, cont, stepping,
shared libraries, reading/writing int/fp registers, etc, but there are
still a lot of details that need to be worked out for full
functionality.

My latest testsuite run results are

                === gdb Summary ===

# of expected passes            45195
# of unexpected failures        1159
# of unexpected successes       3
# of expected failures          56
# of unknown successes          3
# of known failures             63
# of unresolved testcases       138
# of untested testcases         117
# of unsupported tests          121

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.

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.

Jim

Re: contributing the RISC-V linux native port

[Palmer Dabbelt]

On Mon, 06 Aug 2018 19:22:18 PDT (-0700), Jim Wilson wrote:
> I'm wondering about what level of functionality I need to reach before
> it would be reasonable to try to submit my gdb port.  I have a lot of
> basic features working, setting breakpoints, run, cont, stepping,
> shared libraries, reading/writing int/fp registers, etc, but there are
> still a lot of details that need to be worked out for full
> functionality.
>
> My latest testsuite run results are
>
>                 === gdb Summary ===
>
> # of expected passes            45195
> # of unexpected failures        1159
> # of unexpected successes       3
> # of expected failures          56
> # of unknown successes          3
> # of known failures             63
> # of unresolved testcases       138
> # of untested testcases         117
> # of unsupported tests          121
>
> 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.
>
> 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.

While I'm a RISC-V GDB maintainer, I'm far from active so this doesn't carry 
much weight.

In my opinion (having not looked at the code) I think this is sufficient to 
bring the port upstream, as if I understand correctly GDB won't release again 
for six months or so and we should be able to get the major issues cleaned up.  
Since it looks like most of the actual bugs (as opposed to missing features) 
cross projects it'd be great to be able to just point everyone to master on the 
various repos to aid finding the relevant code.  Plus, next time I try to debug 
something I'll probably want to use it and I'm too lazy to find patches unless 
they're upstream :)

Of course, I'll defer to the actual maintainers on this one.

Either way, thanks for getting the port in shape!

Re: contributing the RISC-V linux native port

[Joel Brobecker]

> 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

Re: contributing the RISC-V linux native port

[Jim Wilson]

On Tue, Aug 7, 2018 at 6:01 AM, Joel Brobecker <brobecker@adacore.com> wrote:
> 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.

I don't expect that my patches will cause any problems.  My patch is
improving things for me already.  I've been able to use gdb to debug
binutils, gcc, and gdb issues.  But I'm a command line guy, and don't
use any fancy gdb features, so I'm not sure how it will work for
others.

I've been advertising my personal github tree on riscv mailing lists
and irc, but haven't gotten any direct feedback yet.  I did get some
indirect feedback in the form of a glibc patch from Andreas Schwab so
I suspect that he has tried it.  My tree is at
    https://github.com/jim-wilson/riscv-linux-native-gdb
if anyone wants to look at it.  See the README.md file.

I'll work on a patch set for submission.

Jim

Re: contributing the RISC-V linux native port

[Andreas Schwab]

On Aug 07 2018, Jim Wilson <jimw@sifive.com> wrote:

> I don't expect that my patches will cause any problems.  My patch is
> improving things for me already.  I've been able to use gdb to debug
> binutils, gcc, and gdb issues.  But I'm a command line guy, and don't
> use any fancy gdb features, so I'm not sure how it will work for
> others.

If people find issues with it they will send patches (hopefully).  A
win/win situation.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."