* Re: GDB Python API issues
2011-11-06 2:55 GDB Python API issues Jason Ekstrand
2011-11-06 4:51 ` Hui Zhu
@ 2011-11-07 13:28 ` Tom Tromey
2011-11-07 13:35 ` Phil Muldoon
2 siblings, 0 replies; 4+ messages in thread
From: Tom Tromey @ 2011-11-07 13:28 UTC (permalink / raw)
To: Jason Ekstrand; +Cc: gdb
>>>>> "Jason" == Jason Ekstrand <jason@jlekstrand.net> writes:
Jason> Hi, I've used GDB for a quite a while now, but have never dug into GDB
Jason> development. Recently, I started working on a project that heavily
Jason> abuses GDB's python API. I'm trying to essentially write a more
Jason> up-to-date replacement for DDD that, instead of parsing GDB output or
Jason> tying directly into it on a C level, pulls data from inside using
Jason> GDB's python API.
You could also simply put the GUI inside of gdb... :)
The 'gdb.post_event' function basically exists so you can do this and
run the GUI in a separate thread.
Jason> As I've been working on this project, I've started to find all sorts
Jason> of use cases that the API, as it currently stands, doesn't seem to
Jason> support. I'm willing to help, but I don't quite know where to start
Jason> and I wanted to talk to someone before I start submitting a stream of
Jason> bug reports.
You can bring up ideas and problems here on the list if you like.
A stream of bug reports would also be ok.
Tom
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: GDB Python API issues
2011-11-06 2:55 GDB Python API issues Jason Ekstrand
2011-11-06 4:51 ` Hui Zhu
2011-11-07 13:28 ` Tom Tromey
@ 2011-11-07 13:35 ` Phil Muldoon
2 siblings, 0 replies; 4+ messages in thread
From: Phil Muldoon @ 2011-11-07 13:35 UTC (permalink / raw)
To: Jason Ekstrand; +Cc: gdb
Jason Ekstrand <jason@jlekstrand.net> writes:
> As I've been working on this project, I've started to find all sorts
> of use cases that the API, as it currently stands, doesn't seem to
> support. I'm willing to help, but I don't quite know where to start
> and I wanted to talk to someone before I start submitting a stream of
> bug reports.
Go ahead and submit them, but if you work is considerable, or will be
large in scope, you might want to discuss it first, before committing
hours to coding.
If you work on a bug, assign them to yourself first, other people might
be working on bugs, including ones that you may file. You might find
the CONTRIBUTE guide useful regarding source formatting guidelines, and
other submission related issues. This can be found in the gdb source
directory.
Once you have a patch, you must write a ChangeLog and, depending on the
context, a testsuite patch. All new functionality must, imo, have a
testsuite patch. If your patch adds or changes functionality, it must
include a documentation patch. For new APIs we write a brief entry in
the NEWS file, too. gdb/ doc/ and testsuite/ all have their individual
ChangeLogs.
With the Python API we have a public-facing API promise. We do not
allow API changes once it has been released. So anything that was
included up to 7.3 has to be API stable. We can change the API on new
content since the last release until the next release. If you have to
change the behavior of an API, it must be compatible with the old
behavior. Typically these scenarios are usually parameter changes in
functions. These API differences can normally be worked around with
keyword arguments. Also the API restriction applies to what functions
or APIs return. These things will normally be picked up in review, but
I wanted to note this before you get to work.
When you have all the components together, submit it to:
gdb-patches@sourceware.org. It should be in a unified diff format. It
will be reviewed there. If you do not have FSF copyright assignment
papers, you will have to have that processed before you can commit your
work. A maintainer will help you get that started after your first
patch. Eventually, after a good patch or two, you will be granted
"Commit After Approval" status where you can commit your patches after a
maintainer has approved them through review. Sometimes, patches can go
through a few iterative reviews until you and the maintainer agree on
the patch. Some patches require a documentation review, which will
involve the documentation maintainer. Others may review your patches,
but only a maintainer can approve them.
Finally, if you are working from bugzilla, you must include the PR in
the ChangeLog. There are lots of examples in the gdb/ChangeLog for
this. This triggers a post-commit hook which automatically adds the
commit summary to the bug. You must set the target milestone for the
expected release of the bug. Right now, that would be 7.4.
Hope this helps. I look forward to the patches!
Cheers,
Phil
^ permalink raw reply [flat|nested] 4+ messages in thread