Contributing to gdb

Contributing to gdb

[shaunak saha]

Hi all,

I am new to the community and I'd like to contribute to gdb. I have 15
years of development experience in C mainly working in embedded
domain. Went through the project ideas page
"https://sourceware.org/gdb/wiki/ProjectIdeas". I would be interested
to contribute in areas like Embedded Debugging, watchpoints or
internals. Any suggestion would be great.

Regards,
Shaunak

Re: Contributing to gdb

[Guinevere Larsen]

On 6/14/24 6:52 PM, shaunak saha via Gdb wrote:
> Hi all,
>
> I am new to the community and I'd like to contribute to gdb. I have 15
> years of development experience in C mainly working in embedded
> domain. Went through the project ideas page
> "https://sourceware.org/gdb/wiki/ProjectIdeas". I would be interested
> to contribute in areas like Embedded Debugging, watchpoints or
> internals. Any suggestion would be great.
>
> Regards,
> Shaunak
>
Hello! Welcome welcome, we always love to have new contributors :)

My first thought with regards to that page is that I don't know how up 
to date it is... the last update seems to be back in 2021, which is from 
before I joined the project. That said, I think there is plenty of 
things to do in the areas you mentioned.

For embedded debugging, unfortunately I have no idea what the situation is.

For watchpoints, the first bug that that page mentions is still open, 
but apparently the last mention of anything related to it was in 2014 
(the 2024 comment is unrelated), so you could first check if you can 
still reproduce the issue, and maybe try to fix or close the bug if it 
can't be reproduced anymore. I'm also a big fan of improving user 
experience, so the second thing about watchpoints (and the misuse of the 
word scope) is something I'd love to see, if you're interested in fixing it.

And for internals, if I may do a bit of promotion of my favorite area, 
right now reverse debugging has a big problem: We rely on recording the 
execution history of the inferior in a global variable, which is totally 
not feasible if someone wants to record multiple inferiors at once. I'd 
love to see a rework of this area that makes the history specific to an 
inferior instead of relying on a global var. This could be pretty 
complicated, as I don't exactly know how someone would go about doing 
this and it might touch a couple different subsystems, but if you'd like 
your first contribution to be tough as nails, I know I would love to see 
it :)


Once you decided on something to work on, if it isn't something that 
feels obvious to you or feels like it could depend on some design 
decisions, I recommend sending a very simple prototype as an RFC to the 
gdb-patches@sourceware list, so people can discuss if your approach 
makes sense.

If you want some help understanding some bits of GDB, feel free to reach 
out on IRC (#gdb on libera chat), and if you feel shy about asking 
questions in public, feel free to reach to me privately :) (though I 
mostly only answer on work hours for Brazil).


Just a heads up, too, if your patch isn't a trivial fix, you might need 
to sign a bit of paperwork giving the copyright of changes to GDB to the 
Free Software Foundation before we are able to accept the changes. I 
mention this up front because I know a few people who were turned off by 
the idea, even though the process itself isn't complicated.

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

DCO: Was: Re: Contributing to gdb

[Andrew Pinski]

On Mon, Jun 17, 2024 at 5:23 AM Guinevere Larsen via Gdb
<gdb@sourceware.org> wrote:
> Just a heads up, too, if your patch isn't a trivial fix, you might need
> to sign a bit of paperwork giving the copyright of changes to GDB to the
> Free Software Foundation before we are able to accept the changes. I
> mention this up front because I know a few people who were turned off by
> the idea, even though the process itself isn't complicated.

I just noticed that GDB (and binutils) are currently not accepting
DCO's like both glibc
(https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license)
and GCC (https://gcc.gnu.org/contribute.html#legal) are now accepting.
Has there been any talk about accepting DCOs for gdb and binutils? Or
has this not been brought up yet?

Thanks,
Andrew

>
> --
> Cheers,
> Guinevere Larsen
> She/Her/Hers
>

Re: DCO: Was: Re: Contributing to gdb

[Guinevere Larsen]

On 6/17/24 12:00 PM, Andrew Pinski wrote:
> On Mon, Jun 17, 2024 at 5:23 AM Guinevere Larsen via Gdb
> <gdb@sourceware.org> wrote:
>> Just a heads up, too, if your patch isn't a trivial fix, you might need
>> to sign a bit of paperwork giving the copyright of changes to GDB to the
>> Free Software Foundation before we are able to accept the changes. I
>> mention this up front because I know a few people who were turned off by
>> the idea, even though the process itself isn't complicated.
> I just noticed that GDB (and binutils) are currently not accepting
> DCO's like both glibc
> (https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license)
> and GCC (https://gcc.gnu.org/contribute.html#legal) are now accepting.
> Has there been any talk about accepting DCOs for gdb and binutils? Or
> has this not been brought up yet?

I haven't heard of it yet, every time I see a new contributor with a 
patch accepted, the copyright assignment is always the way everyone 
uses, and it has stalled the last release.

I for one would absolutely love if we could use a quick DCO line instead 
of current process.

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

>
> Thanks,
> Andrew
>
>> --
>> Cheers,
>> Guinevere Larsen
>> She/Her/Hers
>>

Re: DCO: Was: Re: Contributing to gdb

[Jan Beulich]

On 17.06.2024 17:57, Guinevere Larsen wrote:
> On 6/17/24 12:00 PM, Andrew Pinski wrote:
>> On Mon, Jun 17, 2024 at 5:23 AM Guinevere Larsen via Gdb
>> <gdb@sourceware.org> wrote:
>>> Just a heads up, too, if your patch isn't a trivial fix, you might need
>>> to sign a bit of paperwork giving the copyright of changes to GDB to the
>>> Free Software Foundation before we are able to accept the changes. I
>>> mention this up front because I know a few people who were turned off by
>>> the idea, even though the process itself isn't complicated.
>> I just noticed that GDB (and binutils) are currently not accepting
>> DCO's like both glibc
>> (https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license)
>> and GCC (https://gcc.gnu.org/contribute.html#legal) are now accepting.
>> Has there been any talk about accepting DCOs for gdb and binutils? Or
>> has this not been brought up yet?
> 
> I haven't heard of it yet, every time I see a new contributor with a 
> patch accepted, the copyright assignment is always the way everyone 
> uses, and it has stalled the last release.
> 
> I for one would absolutely love if we could use a quick DCO line instead 
> of current process.

Yet binutils/MAINTAINERS already mentions this as a possibility.

Jan

Re: DCO: Was: Re: Contributing to gdb

[Eli Zaretskii]

> Date: Mon, 17 Jun 2024 12:57:41 -0300
> Cc: GDB Development <gdb@sourceware.org>, binutils <binutils@sourceware.org>
> From: Guinevere Larsen via Gdb <gdb@sourceware.org>
> 
> On 6/17/24 12:00 PM, Andrew Pinski wrote:
> > On Mon, Jun 17, 2024 at 5:23 AM Guinevere Larsen via Gdb
> > <gdb@sourceware.org> wrote:
> >> Just a heads up, too, if your patch isn't a trivial fix, you might need
> >> to sign a bit of paperwork giving the copyright of changes to GDB to the
> >> Free Software Foundation before we are able to accept the changes. I
> >> mention this up front because I know a few people who were turned off by
> >> the idea, even though the process itself isn't complicated.
> > I just noticed that GDB (and binutils) are currently not accepting
> > DCO's like both glibc
> > (https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license)
> > and GCC (https://gcc.gnu.org/contribute.html#legal) are now accepting.
> > Has there been any talk about accepting DCOs for gdb and binutils? Or
> > has this not been brought up yet?
> 
> I haven't heard of it yet, every time I see a new contributor with a 
> patch accepted, the copyright assignment is always the way everyone 
> uses, and it has stalled the last release.
> 
> I for one would absolutely love if we could use a quick DCO line instead 
> of current process.

I don't think the risks which come with accepting DCOs are justified
in GDB at least.  The number of one-off contributors to GDB is
basically zero.

Re: DCO: Was: Re: Contributing to gdb

[Guinevere Larsen]

On 6/17/24 1:32 PM, Eli Zaretskii wrote:
>> Date: Mon, 17 Jun 2024 12:57:41 -0300
>> Cc: GDB Development <gdb@sourceware.org>, binutils <binutils@sourceware.org>
>> From: Guinevere Larsen via Gdb <gdb@sourceware.org>
>>
>> On 6/17/24 12:00 PM, Andrew Pinski wrote:
>>> On Mon, Jun 17, 2024 at 5:23 AM Guinevere Larsen via Gdb
>>> <gdb@sourceware.org> wrote:
>>>> Just a heads up, too, if your patch isn't a trivial fix, you might need
>>>> to sign a bit of paperwork giving the copyright of changes to GDB to the
>>>> Free Software Foundation before we are able to accept the changes. I
>>>> mention this up front because I know a few people who were turned off by
>>>> the idea, even though the process itself isn't complicated.
>>> I just noticed that GDB (and binutils) are currently not accepting
>>> DCO's like both glibc
>>> (https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license)
>>> and GCC (https://gcc.gnu.org/contribute.html#legal) are now accepting.
>>> Has there been any talk about accepting DCOs for gdb and binutils? Or
>>> has this not been brought up yet?
>> I haven't heard of it yet, every time I see a new contributor with a
>> patch accepted, the copyright assignment is always the way everyone
>> uses, and it has stalled the last release.
>>
>> I for one would absolutely love if we could use a quick DCO line instead
>> of current process.
> I don't think the risks which come with accepting DCOs are justified
> in GDB at least.  The number of one-off contributors to GDB is
> basically zero.
>
I know of 2 people who decided to not contribute to GDB as soon as I 
mentioned that there was a copyright process.

I also know of one person who I know was be a one off contributor 
(strager, who made a contribution just to make a video on how easy it is 
to contribute to open source projects). And saying we don't have them is 
a chicken and egg problem to me... could it be that we don't have them 
specifically because the process is so hostile to this type of contribution?

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

Re: DCO: Was: Re: Contributing to gdb

[Eli Zaretskii]

> Date: Mon, 17 Jun 2024 13:37:56 -0300
> Cc: pinskia@gmail.com, gdb@sourceware.org, binutils@sourceware.org
> From: Guinevere Larsen <blarsen@redhat.com>
> 
> On 6/17/24 1:32 PM, Eli Zaretskii wrote:
> > I don't think the risks which come with accepting DCOs are justified
> > in GDB at least.  The number of one-off contributors to GDB is
> > basically zero.
> >
> I know of 2 people who decided to not contribute to GDB as soon as I 
> mentioned that there was a copyright process.

And with DCOs they were ready to contribute?

And who talked to them and made sure they understand completely what
copyright assignment means and entails?  IME, a large number of people
have completely distorted idea about that, and are mightily surprised
when told the facts by someone who knows them.

> And saying we don't have them is a chicken and egg problem to
> me... could it be that we don't have them specifically because the
> process is so hostile to this type of contribution?

This goes both ways, you know.

In contrast to the above, which may or may not be true, the risks
associated with accepting DCOs are real, not imaginary and not
"maybe".

Anyway, I don't see a need to argue.  You have expressed your opinion,
and I expressed mine.  We disagree.  It's allowed and is perfectly
okay.

Re: DCO: Was: Re: Contributing to gdb

[Guinevere Larsen]

On 6/17/24 1:45 PM, Eli Zaretskii wrote:
>> Date: Mon, 17 Jun 2024 13:37:56 -0300
>> Cc: pinskia@gmail.com, gdb@sourceware.org, binutils@sourceware.org
>> From: Guinevere Larsen <blarsen@redhat.com>
>>
>> On 6/17/24 1:32 PM, Eli Zaretskii wrote:
>>> I don't think the risks which come with accepting DCOs are justified
>>> in GDB at least.  The number of one-off contributors to GDB is
>>> basically zero.
>>>
>> I know of 2 people who decided to not contribute to GDB as soon as I
>> mentioned that there was a copyright process.
> And with DCOs they were ready to contribute?

Yes. What they didn't want is to do is review an actual legal contract 
and sign it, even before knowing you need to give personal information 
that I am personally uncomfortable giving over the internet to an 
unknown person for a hobby project.

If I am ever not working for someone who has a blanket copyright 
assignment, I'll likely stop contributing code based on that. (I don't 
mean it as a threat since, as things stand, I plan on continuing to work 
professionally on GDB indefinitely, it is just a relevant fact for this 
conversation).

>
> And who talked to them and made sure they understand completely what
> copyright assignment means and entails?  IME, a large number of people
> have completely distorted idea about that, and are mightily surprised
> when told the facts by someone who knows them.
Another problem with this system, then, is scalability. Yes, we don't 
have huge swaths of people eagerly waiting to contribute to GDB, but if 
it is hard enough for regular contributors to find time to review 
patches, where is the time for someone who understands completely the 
copyright assignment to mentor prospective contributors before they are 
turned away when they read that this is a requirement in the 
contribution checklist?
>
>> And saying we don't have them is a chicken and egg problem to
>> me... could it be that we don't have them specifically because the
>> process is so hostile to this type of contribution?
> This goes both ways, you know.
>
> In contrast to the above, which may or may not be true, the risks
> associated with accepting DCOs are real, not imaginary and not
> "maybe".
Could you explain the risks? Not only I am not a lawyer, I have an extra 
large blindspot with regards to copyright law.
>
> Anyway, I don't see a need to argue.  You have expressed your opinion,
> and I expressed mine.  We disagree.  It's allowed and is perfectly
> okay.
>
I would like to change the current system, but I don't have all the 
information, so I think it would be beneficial for us to discuss this so 
that we don't rely on any one person's personal preference, and instead 
choose what is best for the project.

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

Re: DCO: Was: Re: Contributing to gdb

[Andrew Pinski]

On Mon, Jun 17, 2024 at 11:18 AM Guinevere Larsen <blarsen@redhat.com> wrote:
>
> On 6/17/24 1:45 PM, Eli Zaretskii wrote:
> >> Date: Mon, 17 Jun 2024 13:37:56 -0300
> >> Cc: pinskia@gmail.com, gdb@sourceware.org, binutils@sourceware.org
> >> From: Guinevere Larsen <blarsen@redhat.com>
> >>
> >> On 6/17/24 1:32 PM, Eli Zaretskii wrote:
> >>> I don't think the risks which come with accepting DCOs are justified
> >>> in GDB at least.  The number of one-off contributors to GDB is
> >>> basically zero.
> >>>
> >> I know of 2 people who decided to not contribute to GDB as soon as I
> >> mentioned that there was a copyright process.
> > And with DCOs they were ready to contribute?
>
> Yes. What they didn't want is to do is review an actual legal contract
> and sign it, even before knowing you need to give personal information
> that I am personally uncomfortable giving over the internet to an
> unknown person for a hobby project.
>
> If I am ever not working for someone who has a blanket copyright
> assignment, I'll likely stop contributing code based on that. (I don't
> mean it as a threat since, as things stand, I plan on continuing to work
> professionally on GDB indefinitely, it is just a relevant fact for this
> conversation).

The main reason why I brought this up because I know in the near
future (within a year) I will be wanting to help improve/implementing
GDB for aarch64 windows and currently my employer (Qualcomm) does not
have a blanket copyright right assignment and has been ok with the DCO
for submitting patches for GCC and glibc. So this will definitely get
in the way for me here.

Thanks,
Andrew Pinski

>
> >
> > And who talked to them and made sure they understand completely what
> > copyright assignment means and entails?  IME, a large number of people
> > have completely distorted idea about that, and are mightily surprised
> > when told the facts by someone who knows them.
> Another problem with this system, then, is scalability. Yes, we don't
> have huge swaths of people eagerly waiting to contribute to GDB, but if
> it is hard enough for regular contributors to find time to review
> patches, where is the time for someone who understands completely the
> copyright assignment to mentor prospective contributors before they are
> turned away when they read that this is a requirement in the
> contribution checklist?
> >
> >> And saying we don't have them is a chicken and egg problem to
> >> me... could it be that we don't have them specifically because the
> >> process is so hostile to this type of contribution?
> > This goes both ways, you know.
> >
> > In contrast to the above, which may or may not be true, the risks
> > associated with accepting DCOs are real, not imaginary and not
> > "maybe".
> Could you explain the risks? Not only I am not a lawyer, I have an extra
> large blindspot with regards to copyright law.
> >
> > Anyway, I don't see a need to argue.  You have expressed your opinion,
> > and I expressed mine.  We disagree.  It's allowed and is perfectly
> > okay.
> >
> I would like to change the current system, but I don't have all the
> information, so I think it would be beneficial for us to discuss this so
> that we don't rely on any one person's personal preference, and instead
> choose what is best for the project.
>
> --
> Cheers,
> Guinevere Larsen
> She/Her/Hers
>

Re: DCO: Was: Re: Contributing to gdb

[Eli Zaretskii]

> From: Andrew Pinski <pinskia@gmail.com>
> Date: Mon, 17 Jun 2024 11:24:03 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb@sourceware.org, binutils@sourceware.org
> 
> The main reason why I brought this up because I know in the near
> future (within a year) I will be wanting to help improve/implementing
> GDB for aarch64 windows and currently my employer (Qualcomm) does not
> have a blanket copyright right assignment and has been ok with the DCO
> for submitting patches for GCC and glibc. So this will definitely get
> in the way for me here.

You should talk to the FSF lawyers, because I'm not sure you can
contribute based on a DCO in that case.  Your employer can claim they
have the legal rights for the code you wrote.

Re: DCO: Was: Re: Contributing to gdb

[Eli Zaretskii]

> Date: Mon, 17 Jun 2024 15:18:25 -0300
> Cc: pinskia@gmail.com, gdb@sourceware.org, binutils@sourceware.org
> From: Guinevere Larsen <blarsen@redhat.com>
> 
> > And who talked to them and made sure they understand completely what
> > copyright assignment means and entails?  IME, a large number of people
> > have completely distorted idea about that, and are mightily surprised
> > when told the facts by someone who knows them.
> Another problem with this system, then, is scalability. Yes, we don't 
> have huge swaths of people eagerly waiting to contribute to GDB, but if 
> it is hard enough for regular contributors to find time to review 
> patches, where is the time for someone who understands completely the 
> copyright assignment to mentor prospective contributors before they are 
> turned away when they read that this is a requirement in the 
> contribution checklist?

That's not an excuse.  And you can ask me to do that.  I will make
time for it, exactly as I make time to review documentation patches
here, and as I make time to explain this stuff to contributors to
Emacs.

> > In contrast to the above, which may or may not be true, the risks
> > associated with accepting DCOs are real, not imaginary and not
> > "maybe".

> Could you explain the risks? Not only I am not a lawyer, I have an extra 
> large blindspot with regards to copyright law.

They were explained many times on gnu-prog-discuss 3 years ago, so you
are invited to read those discussions.  Basically people misrepresent
themselves as having the rights to contribute code which they have no
legal rights to contribute, and it's likely to happen exactly in the
cases in which the copyright assignment is complicated by the need to
obtain the disclaimer of the employer.

> > Anyway, I don't see a need to argue.  You have expressed your opinion,
> > and I expressed mine.  We disagree.  It's allowed and is perfectly
> > okay.
> >
> I would like to change the current system, but I don't have all the 
> information, so I think it would be beneficial for us to discuss this so 
> that we don't rely on any one person's personal preference, and instead 
> choose what is best for the project.

Anyone who wants to discuss this seriously should first read the
gnu-prog-discuss discussion of these issues, from June 2021 (it went
on all the way through July).

Re: DCO: Was: Re: Contributing to gdb

[Guinevere Larsen]

On 6/17/24 4:37 PM, Eli Zaretskii wrote:
>> Date: Mon, 17 Jun 2024 15:18:25 -0300
>> Cc: pinskia@gmail.com, gdb@sourceware.org, binutils@sourceware.org
>> From: Guinevere Larsen <blarsen@redhat.com>
>>
>>> And who talked to them and made sure they understand completely what
>>> copyright assignment means and entails?  IME, a large number of people
>>> have completely distorted idea about that, and are mightily surprised
>>> when told the facts by someone who knows them.
>> Another problem with this system, then, is scalability. Yes, we don't
>> have huge swaths of people eagerly waiting to contribute to GDB, but if
>> it is hard enough for regular contributors to find time to review
>> patches, where is the time for someone who understands completely the
>> copyright assignment to mentor prospective contributors before they are
>> turned away when they read that this is a requirement in the
>> contribution checklist?
> That's not an excuse.  And you can ask me to do that.  I will make
> time for it, exactly as I make time to review documentation patches
> here, and as I make time to explain this stuff to contributors to
> Emacs.

Then I suggest you add your name and email to the wiki, where the people 
that never even get to the point of interacting with us will find it to 
ask for questions.

https://sourceware.org/gdb/wiki/ContributionChecklist#FSF_copyright_Assignment

>
>>> In contrast to the above, which may or may not be true, the risks
>>> associated with accepting DCOs are real, not imaginary and not
>>> "maybe".
>> Could you explain the risks? Not only I am not a lawyer, I have an extra
>> large blindspot with regards to copyright law.
> They were explained many times on gnu-prog-discuss 3 years ago, so you
> are invited to read those discussions.  Basically people misrepresent
> themselves as having the rights to contribute code which they have no
> legal rights to contribute, and it's likely to happen exactly in the
> cases in which the copyright assignment is complicated by the need to
> obtain the disclaimer of the employer.
>
>>> Anyway, I don't see a need to argue.  You have expressed your opinion,
>>> and I expressed mine.  We disagree.  It's allowed and is perfectly
>>> okay.
>>>
>> I would like to change the current system, but I don't have all the
>> information, so I think it would be beneficial for us to discuss this so
>> that we don't rely on any one person's personal preference, and instead
>> choose what is best for the project.
> Anyone who wants to discuss this seriously should first read the
> gnu-prog-discuss discussion of these issues, from June 2021 (it went
> on all the way through July).
>
Telling someone who actively asked to learn more that "ok, go read those 
email threads" without any convenience like saying the subject to search 
for it easily, or the archive where I can look for it, and furthermore, 
I am forced to subscribe to a list I frankly do not care about just to 
see the discussion you consider required reading before even accepting 
to have a conversation is a very unhelpful way to explain anything for 
anyone.

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

Re: DCO: Was: Re: Contributing to gdb

[Eli Zaretskii]

> Date: Mon, 17 Jun 2024 16:48:13 -0300
> Cc: pinskia@gmail.com, gdb@sourceware.org, binutils@sourceware.org
> From: Guinevere Larsen <blarsen@redhat.com>
> 
> On 6/17/24 4:37 PM, Eli Zaretskii wrote:
> > That's not an excuse.  And you can ask me to do that.  I will make
> > time for it, exactly as I make time to review documentation patches
> > here, and as I make time to explain this stuff to contributors to
> > Emacs.
> 
> Then I suggest you add your name and email to the wiki, where the people 
> that never even get to the point of interacting with us will find it to 
> ask for questions.
> 
> https://sourceware.org/gdb/wiki/ContributionChecklist#FSF_copyright_Assignment

I don't mind, but I didn't see any names and emails mentioned there.
Did I miss something?

> > Anyone who wants to discuss this seriously should first read the
> > gnu-prog-discuss discussion of these issues, from June 2021 (it went
> > on all the way through July).
> >
> Telling someone who actively asked to learn more that "ok, go read those 
> email threads" without any convenience like saying the subject to search 
> for it easily, or the archive where I can look for it, and furthermore, 
> I am forced to subscribe to a list I frankly do not care about just to 
> see the discussion you consider required reading before even accepting 
> to have a conversation is a very unhelpful way to explain anything for 
> anyone.

This must be some grave misunderstanding.  The discussion to which I
pointed was a very long one, took more than a month, and expecting me
(or someone else) to summarize it is unreasonable, even if you ignore
the possibility that a summary might omit aspects that are important
for you, let alone the time required to produce such a summary.  The
gnu-prog-discuss list had a very small number of threads in June 2021,
so I thought finding the right one would be a no-brainer.  But since
it sounds like I was mistaken, I apologize; here's the link to the
beginning of that thread:

  https://lists.gnu.org/mailman/private/gnu-prog-discuss/2021q2/016757.html

The subject of the thread is, unsurprisingly, "Copyright assignments".
It also points to related discussions on GCC, glibc, and Gnulib lists.

The reason I think a serious discussion of this should start by
reading that one is that it doesn't sound a good investment of
everyone's time to re-iterate all the arguments which were already
brought forward there and discussed from every possible aspect.  I
apologize for not making myself clear earlier, and hope I made myself
more clear now: there was no intent to be unhelpful, just an attempt
to be efficient by pointing to a very extensive discussion of this and
related topics.

Re: DCO: Was: Re: Contributing to gdb

[Thiago Jung Bauermann]

Hello Eli,

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Mon, 17 Jun 2024 16:48:13 -0300
>> Cc: pinskia@gmail.com, gdb@sourceware.org, binutils@sourceware.org
>> From: Guinevere Larsen <blarsen@redhat.com>
>> 
> This must be some grave misunderstanding.  The discussion to which I
> pointed was a very long one, took more than a month, and expecting me
> (or someone else) to summarize it is unreasonable, even if you ignore
> the possibility that a summary might omit aspects that are important
> for you, let alone the time required to produce such a summary.  The
> gnu-prog-discuss list had a very small number of threads in June 2021,
> so I thought finding the right one would be a no-brainer.  But since
> it sounds like I was mistaken, I apologize; here's the link to the
> beginning of that thread:
>
>   https://lists.gnu.org/mailman/private/gnu-prog-discuss/2021q2/016757.html
>
> The subject of the thread is, unsurprisingly, "Copyright assignments".
> It also points to related discussions on GCC, glibc, and Gnulib lists.
>
> The reason I think a serious discussion of this should start by
> reading that one is that it doesn't sound a good investment of
> everyone's time to re-iterate all the arguments which were already
> brought forward there and discussed from every possible aspect.  I
> apologize for not making myself clear earlier, and hope I made myself
> more clear now: there was no intent to be unhelpful, just an attempt
> to be efficient by pointing to a very extensive discussion of this and
> related topics.

I'm interested in reading that thread and in the discussion of whether
GDB should accept contributions under the DCO. I don't have a personal
need for it, but my opinion is that it would be beneficial to the GDB
project.

Unfortunately I can't access that mailing list archive: it requires a
password. My understanding is that gnu-prog-discuss is only accessible
to GNU project maintainers.

Would it be possible to copy that mailing list thread to a publicly
accessible location?
-- 
Thiago

Re: DCO: Was: Re: Contributing to gdb

[Eli Zaretskii]

> From: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
> Cc: Guinevere Larsen <blarsen@redhat.com>,  pinskia@gmail.com,
>   gdb@sourceware.org,  binutils@sourceware.org
> Date: Thu, 27 Jun 2024 14:48:00 -0300
> 
> >   https://lists.gnu.org/mailman/private/gnu-prog-discuss/2021q2/016757.html
> >
> > The subject of the thread is, unsurprisingly, "Copyright assignments".
> > It also points to related discussions on GCC, glibc, and Gnulib lists.
> >
> > The reason I think a serious discussion of this should start by
> > reading that one is that it doesn't sound a good investment of
> > everyone's time to re-iterate all the arguments which were already
> > brought forward there and discussed from every possible aspect.  I
> > apologize for not making myself clear earlier, and hope I made myself
> > more clear now: there was no intent to be unhelpful, just an attempt
> > to be efficient by pointing to a very extensive discussion of this and
> > related topics.
> 
> I'm interested in reading that thread and in the discussion of whether
> GDB should accept contributions under the DCO. I don't have a personal
> need for it, but my opinion is that it would be beneficial to the GDB
> project.
> 
> Unfortunately I can't access that mailing list archive: it requires a
> password. My understanding is that gnu-prog-discuss is only accessible
> to GNU project maintainers.

I'm not sure this is true.  Did you try subscribing?

> Would it be possible to copy that mailing list thread to a publicly
> accessible location?

That's not for me to decide, please talk to the list admins.

Re: DCO: Was: Re: Contributing to gdb

[Thiago Jung Bauermann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
>> Cc: Guinevere Larsen <blarsen@redhat.com>,  pinskia@gmail.com,
>>   gdb@sourceware.org,  binutils@sourceware.org
>> Date: Thu, 27 Jun 2024 14:48:00 -0300
>> 
>> >   https://lists.gnu.org/mailman/private/gnu-prog-discuss/2021q2/016757.html
>> >
>> > The subject of the thread is, unsurprisingly, "Copyright assignments".
>> > It also points to related discussions on GCC, glibc, and Gnulib lists.
>> >
>> > The reason I think a serious discussion of this should start by
>> > reading that one is that it doesn't sound a good investment of
>> > everyone's time to re-iterate all the arguments which were already
>> > brought forward there and discussed from every possible aspect.  I
>> > apologize for not making myself clear earlier, and hope I made myself
>> > more clear now: there was no intent to be unhelpful, just an attempt
>> > to be efficient by pointing to a very extensive discussion of this and
>> > related topics.
>> 
>> I'm interested in reading that thread and in the discussion of whether
>> GDB should accept contributions under the DCO. I don't have a personal
>> need for it, but my opinion is that it would be beneficial to the GDB
>> project.
>> 
>> Unfortunately I can't access that mailing list archive: it requires a
>> password. My understanding is that gnu-prog-discuss is only accessible
>> to GNU project maintainers.
>
> I'm not sure this is true.  Did you try subscribing?

I did, and I was accepted. Thank you for the suggestion.
FWIW, I found this information about the mailing list¹:

  gnu-prog[+discuss] subscription requests?

  Membership in the gnu-prog and gnu-prog-discuss mailing lists is
  restricted to direct GNU contributors, and thus moderated.

  Question: Is there a recipe for knowing when to approve and when to
  discard subscription requests?

  Answer from Karl:

      If the person is in the fp:/gd/gnuorg/maintainers file,
          ok to approve.
      If the person has an account on fencepost,
          ok to approve.
      If the person is a member of GNU (not nongnu) package on Savannah,
          ok to approve.
      When in doubt, ask maintainers@gnu.org before approving.

>> Would it be possible to copy that mailing list thread to a publicly
>> accessible location?
>
> That's not for me to decide, please talk to the list admins.

Ok, I'll ask.
-- 
Thiago

¹ https://savannah.gnu.org/maintenance/MailingListNotes/

Re: DCO: Was: Re: Contributing to gdb

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]

Guinevere Larsen <blarsen@redhat.com> writes:

> I know of 2 people who decided to not contribute to GDB as soon as I mentioned
> that there was a copyright process.
>
> I also know of one person who I know was be a one off contributor (strager, who
> made a contribution just to make a video on how easy it is to contribute to
> open source projects). And saying we don't have them is a chicken and egg
> problem to me... could it be that we don't have them specifically because the
> process is so hostile to this type of contribution?

I know some people who refuse to contribute due to this also.  Many
don't trust the FSF, many don't want to reveal information, many do not
see the difference between the FSF copyright process and a CLA (except
that the latter is often easier to process..).

I understand there are good reasons for copyright assignment to the FSF,
but the FSF seems to be considered less trustworthy nowadays, and this
is reflected in the likelihood of (even relatively experienced!) free
software contributors signing over copyright.

I've, for a long time, avoided contributing to projects with 'legal
routine' requirements (DCO included) due to the implications of sharing
real names.

(NOTE: I have copyright assignments on file and might file more
 ahead-of-time to avoid sinking time every time I contribute to a new
 project.  It has not stopped me, but it /has/ others.  I can completely
 understand those people also)
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: DCO: Was: Re: Contributing to gdb

[Eli Zaretskii]

> From: Arsen Arsenović <arsen@aarsen.me>
> Cc: Eli Zaretskii <eliz@gnu.org>,  pinskia@gmail.com,  gdb@sourceware.org,
>   binutils@sourceware.org
> Date: Mon, 17 Jun 2024 21:15:58 +0200
> 
> I know some people who refuse to contribute due to this also.

That's not necessarily relevant.  We are interested in potential
contributors to GDB, who have either some code to contribute or some
practical ideas for such code, not just some people out there.

> Many don't trust the FSF, many don't want to reveal information,
> many do not see the difference between the FSF copyright process and
> a CLA (except that the latter is often easier to process..).

In general, yes, some (not many!) do.  But IME with maintaining Emacs,
I have yet to bump into a person who has code to contribute and whom I
couldn't convince that the copyright assignment is not a problem (if
they even thought that to begin with).

> I understand there are good reasons for copyright assignment to the FSF,
> but the FSF seems to be considered less trustworthy nowadays, and this
> is reflected in the likelihood of (even relatively experienced!) free
> software contributors signing over copyright.

Again, not IME.

> I've, for a long time, avoided contributing to projects with 'legal
> routine' requirements (DCO included) due to the implications of sharing
> real names.

There's no need to share a real name.  The assignments on file have
quite a few names that are withheld, with only a pseudonym on file.
This is a non-issue, for all practical purposes.  And, as you point
out, using DCOs doesn't change this aspect in any way.

> (NOTE: I have copyright assignments on file and might file more
>  ahead-of-time to avoid sinking time every time I contribute to a new
>  project.  It has not stopped me, but it /has/ others.  I can completely
>  understand those people also)

I understand them also.  I'm just saying that we should patiently
explain them the facts about the assignment's meaning and practices,
and IME that has an almost 100% success rate.

Re: DCO: Was: Re: Contributing to gdb

[NightStrike]

On Tue, Jun 18, 2024 at 7:55 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Arsen Arsenović <arsen@aarsen.me>
> > I've, for a long time, avoided contributing to projects with 'legal
> > routine' requirements (DCO included) due to the implications of sharing
> > real names.
>
> There's no need to share a real name.  The assignments on file have
> quite a few names that are withheld, with only a pseudonym on file.
> This is a non-issue, for all practical purposes.  And, as you point
> out, using DCOs doesn't change this aspect in any way.

Is this really true?  I was denied being able to work on GCC for this
reason (many years ago, before DCO), because I refused to reveal my
PII.  I pointed out that a real-sounding fake name is no better than a
fake-sounding fake name, which eventually led to someone (I think Ian)
explaining that sharing your name is only the first step in validating
someone's identity.  I never pursued it further.

Can you please explain how copyright assignments are validated if you
don't have to share your real name, as opposed to providing a
real-sounding fake name?  This one point has prevented my own
contributions since 2008; I've limited myself to simply running tests
and opening PR's.

Re: DCO: Was: Re: Contributing to gdb

[Eli Zaretskii]

> From: NightStrike <nightstrike@gmail.com>
> Date: Thu, 27 Jun 2024 20:43:05 -0400
> Cc: Arsen Arsenović <arsen@aarsen.me>, blarsen@redhat.com, 
> 	pinskia@gmail.com, gdb@sourceware.org, binutils@sourceware.org
> 
> On Tue, Jun 18, 2024 at 7:55 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > > From: Arsen Arsenović <arsen@aarsen.me>
> > > I've, for a long time, avoided contributing to projects with 'legal
> > > routine' requirements (DCO included) due to the implications of sharing
> > > real names.
> >
> > There's no need to share a real name.  The assignments on file have
> > quite a few names that are withheld, with only a pseudonym on file.
> > This is a non-issue, for all practical purposes.  And, as you point
> > out, using DCOs doesn't change this aspect in any way.
> 
> Is this really true?  I was denied being able to work on GCC for this
> reason (many years ago, before DCO), because I refused to reveal my
> PII.  I pointed out that a real-sounding fake name is no better than a
> fake-sounding fake name, which eventually led to someone (I think Ian)
> explaining that sharing your name is only the first step in validating
> someone's identity.  I never pursued it further.

IME, it's true.  Like I said, I see in the assignments on file names
of people that are pseudonyms, with real names "withheld".

> Can you please explain how copyright assignments are validated if you
> don't have to share your real name, as opposed to providing a
> real-sounding fake name?  This one point has prevented my own
> contributions since 2008; I've limited myself to simply running tests
> and opening PR's.

If you are asking me from the POV of a maintainer of a GNU project
(Emacs), then whether the name is real or not doesn't bother me.  As
long as the assignment for "Some Name <some@email.address>" is on
file, I accept the contributions, no questions asked.

If you are asking me from the POV of the FSF copyright-assignment
clerk, the person who deals with the copyright-assignment process,
then I don't know how they do it.  I suggest to ask them.  They can be
reached at copyright-clerk@fsf.org.

Re: DCO: Was: Re: Contributing to gdb

[Nick Clifton]

Hi Gwen, Hi Andrew,
>> I just noticed that GDB (and binutils) are currently not accepting
>> DCO's like both glibc

The GNU Binutils *does* accept contributions signed with a DCO:

   https://sourceware.org/binutils/wiki/HowToContribute

This change has been in place since October 2022.

Cheers
   Nick

Re: DCO: Was: Re: Contributing to gdb

[Tom Tromey]

>> I just noticed that GDB (and binutils) are currently not accepting
>> DCO's like both glibc
>> (https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license)
>> and GCC (https://gcc.gnu.org/contribute.html#legal) are now accepting.
>> Has there been any talk about accepting DCOs for gdb and binutils? Or
>> has this not been brought up yet?

If gcc, glibc, and binutils accept it, then IMO gdb should as well.

Tom

Re: DCO: Was: Re: Contributing to gdb

[Michael Matz]

Hello,

On Mon, 17 Jun 2024, Andrew Pinski wrote:

> I just noticed that GDB (and binutils) are currently not accepting
> DCO's like both glibc
> (https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license)
> and GCC (https://gcc.gnu.org/contribute.html#legal) are now accepting.

That is incorrect for binutils.  DCO contributions are accepted, as stated 
in binutils/MAINTAINERS.  (Discussed during some past Cauldron)


Ciao,
Michael.

Re: Contributing to gdb

[shaunak saha]

Hi,

>>Hello! Welcome welcome, we always love to have new contributors :)

Thanks a lot for the warm welcome.

>>For watchpoints, the first bug that that page mentions is still open,
>>but apparently the last mention of anything related to it was in 2014
>>(the 2024 comment is unrelated), so you could first check if you can
>>still reproduce the issue, and maybe try to fix or close the bug if it
>>can't be reproduced anymore. I'm also a big fan of improving user
>>experience, so the second thing about watchpoints (and the misuse of the
>>word scope) is something I'd love to see, if you're interested in fixing it.

Sure, I will check as this will help me to get used to the gdb
development environment also better. Just to confirm, Is this the bug
you mentioned? "https://sourceware.org/bugzilla/show_bug.cgi?id=10645"

>>And for internals, if I may do a bit of promotion of my favorite area,
>>right now reverse debugging has a big problem: We rely on recording the
>>execution history of the inferior in a global variable, which is totally
>>not feasible if someone wants to record multiple inferiors at once. I'd
>>love to see a rework of this area that makes the history specific to an
>>inferior instead of relying on a global var. This could be pretty
>>complicated, as I don't exactly know how someone would go about doing
>>this and it might touch a couple different subsystems, but if you'd like
>>your first contribution to be tough as nails, I know I would love to see
>>it :)
Actually this is one of the areas I am very interested in too. This
would be a really good learning experience for me. For the rework of
the global variable issues can you please point me to the bug if it's
there. I can start by learning more about it.

>>If you want some help understanding some bits of GDB, feel free to reach
>>out on IRC (#gdb on libera chat), and if you feel shy about asking
>>questions in public, feel free to reach to me privately :) (though I
>>mostly only answer on work hours for Brazil).

Thanks a lot. I will reach out on IRC or ask you over email for my doubts.

>>Just a heads up, too, if your patch isn't a trivial fix, you might need
>>to sign a bit of paperwork giving the copyright of changes to GDB to the
>>Free Software Foundation before we are able to accept the changes. I
>>mention this up front because I know a few people who were turned off by
>>the idea, even though the process itself isn't complicated.

I understand. I am ok with signing the paperwork with FSF. I am
guessing that would not be a problem with my employer but I will still
check.

Regards,
Shaunak

On Mon, Jun 17, 2024 at 5:22 AM Guinevere Larsen <blarsen@redhat.com> wrote:
>
> On 6/14/24 6:52 PM, shaunak saha via Gdb wrote:
> > Hi all,
> >
> > I am new to the community and I'd like to contribute to gdb. I have 15
> > years of development experience in C mainly working in embedded
> > domain. Went through the project ideas page
> > "https://sourceware.org/gdb/wiki/ProjectIdeas". I would be interested
> > to contribute in areas like Embedded Debugging, watchpoints or
> > internals. Any suggestion would be great.
> >
> > Regards,
> > Shaunak
> >
> Hello! Welcome welcome, we always love to have new contributors :)
>
> My first thought with regards to that page is that I don't know how up
> to date it is... the last update seems to be back in 2021, which is from
> before I joined the project. That said, I think there is plenty of
> things to do in the areas you mentioned.
>
> For embedded debugging, unfortunately I have no idea what the situation is.
>
> For watchpoints, the first bug that that page mentions is still open,
> but apparently the last mention of anything related to it was in 2014
> (the 2024 comment is unrelated), so you could first check if you can
> still reproduce the issue, and maybe try to fix or close the bug if it
> can't be reproduced anymore. I'm also a big fan of improving user
> experience, so the second thing about watchpoints (and the misuse of the
> word scope) is something I'd love to see, if you're interested in fixing it.
>
> And for internals, if I may do a bit of promotion of my favorite area,
> right now reverse debugging has a big problem: We rely on recording the
> execution history of the inferior in a global variable, which is totally
> not feasible if someone wants to record multiple inferiors at once. I'd
> love to see a rework of this area that makes the history specific to an
> inferior instead of relying on a global var. This could be pretty
> complicated, as I don't exactly know how someone would go about doing
> this and it might touch a couple different subsystems, but if you'd like
> your first contribution to be tough as nails, I know I would love to see
> it :)
>
>
> Once you decided on something to work on, if it isn't something that
> feels obvious to you or feels like it could depend on some design
> decisions, I recommend sending a very simple prototype as an RFC to the
> gdb-patches@sourceware list, so people can discuss if your approach
> makes sense.
>
> If you want some help understanding some bits of GDB, feel free to reach
> out on IRC (#gdb on libera chat), and if you feel shy about asking
> questions in public, feel free to reach to me privately :) (though I
> mostly only answer on work hours for Brazil).
>
>
> Just a heads up, too, if your patch isn't a trivial fix, you might need
> to sign a bit of paperwork giving the copyright of changes to GDB to the
> Free Software Foundation before we are able to accept the changes. I
> mention this up front because I know a few people who were turned off by
> the idea, even though the process itself isn't complicated.
>
> --
> Cheers,
> Guinevere Larsen
> She/Her/Hers
>

Re: Contributing to gdb

[Guinevere Larsen]

On 6/19/24 4:38 AM, shaunak saha wrote:
> Hi,
>
>>> Hello! Welcome welcome, we always love to have new contributors :)
> Thanks a lot for the warm welcome.
>
>>> For watchpoints, the first bug that that page mentions is still open,
>>> but apparently the last mention of anything related to it was in 2014
>>> (the 2024 comment is unrelated), so you could first check if you can
>>> still reproduce the issue, and maybe try to fix or close the bug if it
>>> can't be reproduced anymore. I'm also a big fan of improving user
>>> experience, so the second thing about watchpoints (and the misuse of the
>>> word scope) is something I'd love to see, if you're interested in fixing it.
> Sure, I will check as this will help me to get used to the gdb
> development environment also better. Just to confirm, Is this the bug
> you mentioned? "https://sourceware.org/bugzilla/show_bug.cgi?id=10645"
Yes, this was the bug I was thinking of.
>
>>> And for internals, if I may do a bit of promotion of my favorite area,
>>> right now reverse debugging has a big problem: We rely on recording the
>>> execution history of the inferior in a global variable, which is totally
>>> not feasible if someone wants to record multiple inferiors at once. I'd
>>> love to see a rework of this area that makes the history specific to an
>>> inferior instead of relying on a global var. This could be pretty
>>> complicated, as I don't exactly know how someone would go about doing
>>> this and it might touch a couple different subsystems, but if you'd like
>>> your first contribution to be tough as nails, I know I would love to see
>>> it :)
> Actually this is one of the areas I am very interested in too. This
> would be a really good learning experience for me. For the rework of
> the global variable issues can you please point me to the bug if it's
> there. I can start by learning more about it.

There wasn't a bug yet, but I just created one 
https://sourceware.org/bugzilla/show_bug.cgi?id=31911

I tried to add my thoughts on how this could be done, but this was 
thought in the moment, no real research into what's possible or 
reasonable. I just so happened to  be working close to this area and had 
many unstructured thoughts hahaha

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

>
>>> If you want some help understanding some bits of GDB, feel free to reach
>>> out on IRC (#gdb on libera chat), and if you feel shy about asking
>>> questions in public, feel free to reach to me privately :) (though I
>>> mostly only answer on work hours for Brazil).
> Thanks a lot. I will reach out on IRC or ask you over email for my doubts.
>
>>> Just a heads up, too, if your patch isn't a trivial fix, you might need
>>> to sign a bit of paperwork giving the copyright of changes to GDB to the
>>> Free Software Foundation before we are able to accept the changes. I
>>> mention this up front because I know a few people who were turned off by
>>> the idea, even though the process itself isn't complicated.
> I understand. I am ok with signing the paperwork with FSF. I am
> guessing that would not be a problem with my employer but I will still
> check.
>
> Regards,
> Shaunak
>
> On Mon, Jun 17, 2024 at 5:22 AM Guinevere Larsen <blarsen@redhat.com> wrote:
>> On 6/14/24 6:52 PM, shaunak saha via Gdb wrote:
>>> Hi all,
>>>
>>> I am new to the community and I'd like to contribute to gdb. I have 15
>>> years of development experience in C mainly working in embedded
>>> domain. Went through the project ideas page
>>> "https://sourceware.org/gdb/wiki/ProjectIdeas". I would be interested
>>> to contribute in areas like Embedded Debugging, watchpoints or
>>> internals. Any suggestion would be great.
>>>
>>> Regards,
>>> Shaunak
>>>
>> Hello! Welcome welcome, we always love to have new contributors :)
>>
>> My first thought with regards to that page is that I don't know how up
>> to date it is... the last update seems to be back in 2021, which is from
>> before I joined the project. That said, I think there is plenty of
>> things to do in the areas you mentioned.
>>
>> For embedded debugging, unfortunately I have no idea what the situation is.
>>
>> For watchpoints, the first bug that that page mentions is still open,
>> but apparently the last mention of anything related to it was in 2014
>> (the 2024 comment is unrelated), so you could first check if you can
>> still reproduce the issue, and maybe try to fix or close the bug if it
>> can't be reproduced anymore. I'm also a big fan of improving user
>> experience, so the second thing about watchpoints (and the misuse of the
>> word scope) is something I'd love to see, if you're interested in fixing it.
>>
>> And for internals, if I may do a bit of promotion of my favorite area,
>> right now reverse debugging has a big problem: We rely on recording the
>> execution history of the inferior in a global variable, which is totally
>> not feasible if someone wants to record multiple inferiors at once. I'd
>> love to see a rework of this area that makes the history specific to an
>> inferior instead of relying on a global var. This could be pretty
>> complicated, as I don't exactly know how someone would go about doing
>> this and it might touch a couple different subsystems, but if you'd like
>> your first contribution to be tough as nails, I know I would love to see
>> it :)
>>
>>
>> Once you decided on something to work on, if it isn't something that
>> feels obvious to you or feels like it could depend on some design
>> decisions, I recommend sending a very simple prototype as an RFC to the
>> gdb-patches@sourceware list, so people can discuss if your approach
>> makes sense.
>>
>> If you want some help understanding some bits of GDB, feel free to reach
>> out on IRC (#gdb on libera chat), and if you feel shy about asking
>> questions in public, feel free to reach to me privately :) (though I
>> mostly only answer on work hours for Brazil).
>>
>>
>> Just a heads up, too, if your patch isn't a trivial fix, you might need
>> to sign a bit of paperwork giving the copyright of changes to GDB to the
>> Free Software Foundation before we are able to accept the changes. I
>> mention this up front because I know a few people who were turned off by
>> the idea, even though the process itself isn't complicated.
>>
>> --
>> Cheers,
>> Guinevere Larsen
>> She/Her/Hers
>>

Re: Contributing to gdb

[shaunak saha]

[-- Attachment #1: Type: text/plain, Size: 8195 bytes --]

Hi Guinevere,

Thanks for confirming. I checked the bug 10645 in an x86 system. I don't
see the issue anymore:

Continuing.
[infrun] clear_proceed_status_thread: 17395.17395.0
[infrun] proceed: enter
  [infrun] follow_fork: enter
  [infrun] follow_fork: exit
  [infrun] proceed: cur_thr = 17395.17395.0
  [infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT,
resume_ptid=17395.0.0
  [infrun] scoped_disable_commit_resumed: reason=proceeding
  [infrun] start_step_over: enter
    [infrun] start_step_over: stealing global queue of threads to step,
length = 0
    [infrun] operator(): step-over queue now empty
  [infrun] start_step_over: exit
  [infrun] proceed: start: resuming threads, all-stop-on-top-of-non-stop
    [infrun] proceed_resume_thread_checked: resuming 17395.17395.0
    [infrun] resume_1:* step=0*, signal=GDB_SIGNAL_0, trap_expected=0,
current thread [17395.17395.0] at 0x55555555514b
    [infrun] do_target_resume: resume_ptid=17395.17395.0, step=0,
sig=GDB_SIGNAL_0
  [infrun] proceed: end: resuming threads, all-stop-on-top-of-non-stop
  [infrun] reset: reason=proceeding

I can see the step is 0.

>https://sourceware.org/bugzilla/show_bug.cgi?id=31911
Thanks for creating the bug. I am looking into it and trying to understand
the code.

Regards,
Shaunak




On Wed, Jun 19, 2024 at 5:07 AM Guinevere Larsen <blarsen@redhat.com> wrote:

> On 6/19/24 4:38 AM, shaunak saha wrote:
> > Hi,
> >
> >>> Hello! Welcome welcome, we always love to have new contributors :)
> > Thanks a lot for the warm welcome.
> >
> >>> For watchpoints, the first bug that that page mentions is still open,
> >>> but apparently the last mention of anything related to it was in 2014
> >>> (the 2024 comment is unrelated), so you could first check if you can
> >>> still reproduce the issue, and maybe try to fix or close the bug if it
> >>> can't be reproduced anymore. I'm also a big fan of improving user
> >>> experience, so the second thing about watchpoints (and the misuse of
> the
> >>> word scope) is something I'd love to see, if you're interested in
> fixing it.
> > Sure, I will check as this will help me to get used to the gdb
> > development environment also better. Just to confirm, Is this the bug
> > you mentioned? "https://sourceware.org/bugzilla/show_bug.cgi?id=10645"
> Yes, this was the bug I was thinking of.
> >
> >>> And for internals, if I may do a bit of promotion of my favorite area,
> >>> right now reverse debugging has a big problem: We rely on recording the
> >>> execution history of the inferior in a global variable, which is
> totally
> >>> not feasible if someone wants to record multiple inferiors at once. I'd
> >>> love to see a rework of this area that makes the history specific to an
> >>> inferior instead of relying on a global var. This could be pretty
> >>> complicated, as I don't exactly know how someone would go about doing
> >>> this and it might touch a couple different subsystems, but if you'd
> like
> >>> your first contribution to be tough as nails, I know I would love to
> see
> >>> it :)
> > Actually this is one of the areas I am very interested in too. This
> > would be a really good learning experience for me. For the rework of
> > the global variable issues can you please point me to the bug if it's
> > there. I can start by learning more about it.
>
> There wasn't a bug yet, but I just created one
> https://sourceware.org/bugzilla/show_bug.cgi?id=31911
>
> I tried to add my thoughts on how this could be done, but this was
> thought in the moment, no real research into what's possible or
> reasonable. I just so happened to  be working close to this area and had
> many unstructured thoughts hahaha
>
> --
> Cheers,
> Guinevere Larsen
> She/Her/Hers
>
> >
> >>> If you want some help understanding some bits of GDB, feel free to
> reach
> >>> out on IRC (#gdb on libera chat), and if you feel shy about asking
> >>> questions in public, feel free to reach to me privately :) (though I
> >>> mostly only answer on work hours for Brazil).
> > Thanks a lot. I will reach out on IRC or ask you over email for my
> doubts.
> >
> >>> Just a heads up, too, if your patch isn't a trivial fix, you might need
> >>> to sign a bit of paperwork giving the copyright of changes to GDB to
> the
> >>> Free Software Foundation before we are able to accept the changes. I
> >>> mention this up front because I know a few people who were turned off
> by
> >>> the idea, even though the process itself isn't complicated.
> > I understand. I am ok with signing the paperwork with FSF. I am
> > guessing that would not be a problem with my employer but I will still
> > check.
> >
> > Regards,
> > Shaunak
> >
> > On Mon, Jun 17, 2024 at 5:22 AM Guinevere Larsen <blarsen@redhat.com>
> wrote:
> >> On 6/14/24 6:52 PM, shaunak saha via Gdb wrote:
> >>> Hi all,
> >>>
> >>> I am new to the community and I'd like to contribute to gdb. I have 15
> >>> years of development experience in C mainly working in embedded
> >>> domain. Went through the project ideas page
> >>> "https://sourceware.org/gdb/wiki/ProjectIdeas". I would be interested
> >>> to contribute in areas like Embedded Debugging, watchpoints or
> >>> internals. Any suggestion would be great.
> >>>
> >>> Regards,
> >>> Shaunak
> >>>
> >> Hello! Welcome welcome, we always love to have new contributors :)
> >>
> >> My first thought with regards to that page is that I don't know how up
> >> to date it is... the last update seems to be back in 2021, which is from
> >> before I joined the project. That said, I think there is plenty of
> >> things to do in the areas you mentioned.
> >>
> >> For embedded debugging, unfortunately I have no idea what the situation
> is.
> >>
> >> For watchpoints, the first bug that that page mentions is still open,
> >> but apparently the last mention of anything related to it was in 2014
> >> (the 2024 comment is unrelated), so you could first check if you can
> >> still reproduce the issue, and maybe try to fix or close the bug if it
> >> can't be reproduced anymore. I'm also a big fan of improving user
> >> experience, so the second thing about watchpoints (and the misuse of the
> >> word scope) is something I'd love to see, if you're interested in
> fixing it.
> >>
> >> And for internals, if I may do a bit of promotion of my favorite area,
> >> right now reverse debugging has a big problem: We rely on recording the
> >> execution history of the inferior in a global variable, which is totally
> >> not feasible if someone wants to record multiple inferiors at once. I'd
> >> love to see a rework of this area that makes the history specific to an
> >> inferior instead of relying on a global var. This could be pretty
> >> complicated, as I don't exactly know how someone would go about doing
> >> this and it might touch a couple different subsystems, but if you'd like
> >> your first contribution to be tough as nails, I know I would love to see
> >> it :)
> >>
> >>
> >> Once you decided on something to work on, if it isn't something that
> >> feels obvious to you or feels like it could depend on some design
> >> decisions, I recommend sending a very simple prototype as an RFC to the
> >> gdb-patches@sourceware list, so people can discuss if your approach
> >> makes sense.
> >>
> >> If you want some help understanding some bits of GDB, feel free to reach
> >> out on IRC (#gdb on libera chat), and if you feel shy about asking
> >> questions in public, feel free to reach to me privately :) (though I
> >> mostly only answer on work hours for Brazil).
> >>
> >>
> >> Just a heads up, too, if your patch isn't a trivial fix, you might need
> >> to sign a bit of paperwork giving the copyright of changes to GDB to the
> >> Free Software Foundation before we are able to accept the changes. I
> >> mention this up front because I know a few people who were turned off by
> >> the idea, even though the process itself isn't complicated.
> >>
> >> --
> >> Cheers,
> >> Guinevere Larsen
> >> She/Her/Hers
> >>
>
>

Re: Contributing to gdb

[Tom Tromey]

>>>>> "shaunak" == shaunak saha via Gdb <gdb@sourceware.org> writes:

shaunak> I am new to the community and I'd like to contribute to gdb. I have 15
shaunak> years of development experience in C mainly working in embedded
shaunak> domain. Went through the project ideas page
shaunak> "https://sourceware.org/gdb/wiki/ProjectIdeas". I would be interested
shaunak> to contribute in areas like Embedded Debugging, watchpoints or
shaunak> internals. Any suggestion would be great.

In addition to what Guinevere said, there's a good-first-bug keyword in
bugzilla.  These are bugs that are expected to not be too difficult and
can be a good starting point.

https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&f1=keywords&keywords=good-first-bug%2C%20&keywords_type=allwords&list_id=84360&product=gdb&query_format=advanced

Tom

Re: Contributing to gdb

[shaunak saha]

[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]

Thanks Tom.

-Shaunak

On Wed, Jun 26, 2024 at 10:38 AM Tom Tromey <tom@tromey.com> wrote:

> >>>>> "shaunak" == shaunak saha via Gdb <gdb@sourceware.org> writes:
>
> shaunak> I am new to the community and I'd like to contribute to gdb. I
> have 15
> shaunak> years of development experience in C mainly working in embedded
> shaunak> domain. Went through the project ideas page
> shaunak> "https://sourceware.org/gdb/wiki/ProjectIdeas". I would be
> interested
> shaunak> to contribute in areas like Embedded Debugging, watchpoints or
> shaunak> internals. Any suggestion would be great.
>
> In addition to what Guinevere said, there's a good-first-bug keyword in
> bugzilla.  These are bugs that are expected to not be too difficult and
> can be a good starting point.
>
>
> https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&f1=keywords&keywords=good-first-bug%2C%20&keywords_type=allwords&list_id=84360&product=gdb&query_format=advanced
>
> Tom
>