Contributing to GDB

Contributing to GDB

[mydeen]

Hi,
    I was traversing the GDB Mailing list. I am intrested in contributing
  to the GDB development and testing. Can u please suggest any area
  related to GDB that can make me to take part in development actively.

  I am comfortable under Unix Platform,especially Linux, Solaris and FreeBSD.

  Your suggestions will be very helpful to me in getting started.

 Thanks
Mydeen

Re: Contributing to GDB

[Daniel Jacobowitz]

On Sat, Feb 04, 2006 at 07:19:23AM -0500, mydeen wrote:
> Hi,
>     I was traversing the GDB Mailing list. I am intrested in contributing
>   to the GDB development and testing. Can u please suggest any area
>   related to GDB that can make me to take part in development actively.
> 
>   I am comfortable under Unix Platform,especially Linux, Solaris and FreeBSD.
> 
>   Your suggestions will be very helpful to me in getting started.
> 
>  Thanks
> Mydeen

Hi Mydeen,

One useful thing you could do would be to take a look at the bug
tracking system, and try to reproduce and fix user bug reports.
Some of the old bug reports in GNATS are still there because they're
hard; many others are only still there because no one has looked at
them.

-- 
Daniel Jacobowitz
CodeSourcery

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

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
>