* Changes
@ 2008-07-09 22:19 Tom Tromey
2008-07-10 0:06 ` Changes Sami Wagiaalla
` (4 more replies)
0 siblings, 5 replies; 13+ messages in thread
From: Tom Tromey @ 2008-07-09 22:19 UTC (permalink / raw)
To: Frysk List
Here's the first message of the messages I promised during the
meeting.
Red Hat is revisiting its interest in Frysk. In particular, our goal
is now:
Build the best C++ debugger in the world.
This has a few sub-goals:
* Have a CLI
* Integrate with Eclipse
* Scale to very large programs (w/ lots of shared libraries)
* Scale to many threads
In particular I think Red Hat is not going to pursue Frysk's current
monitoring and tracing goals, or the existing GUI.
I'm sending everything in this message to this list. However, if the
consensus is that we need a new list, that would also be fine by me.
Meanwhile I'll carry on here.
Internally we've revisited a number of decisions made during the
course of Frysk's development. I'll summarize here our current
thinking about what we'd like to do. Comments, criticism, etc are
welcome.
Note that I'm using the Red Hat "we" in the below. I'm sure that
individuals disagree with various statements here. (Feel free to
speak up, etc.) I am responsible for anything you read here, and I
don't want to avoid that, but I did not want to take undue credit for
ideas, etc, which are not mine.
* Java. We've heard many times while discussing Frysk with other
parties that the choice of Java is an odd one.
In order to more fully align the interests of the developers of the
debugger with the interests of its users, we'd like to use C++ as
the implementation language. We picture refactoring the core of
Frysk into C++; not changing the design but simply the
implementation language.
* Scripting. One issue with gdb is its poor support for scripting.
We think scripting is needed for debugger programmability, and in
particular that it will be needed for C++ pretty-printing. So, our
thinking is that this debugger would have a Python binding to its
core.
In order to exercise this binding code, we picture rewriting the
existing CLI code in Python. The idea here is that part of the CLI
need a rewrite anyhow, and there is no particular reason that the
CLI needs to be written in C++.
* HPD. We discussed HPD a little. It seems ok, overall, though a bit
underpowered; in particular there are common debugging operations
that one can do in gdb which have no analog in HPD. So, we know we
must at least extend it.
Some people expressed concern that the HPD language differs
needlessly from gdb -- meaning that they need to re-learn things to
try a new debugger. I don't think we have a particular solution in
mind for this. We could move more toward a gdb-like CLI, or we
could supply a compatibility mode; dunno.
We think it makes sense to still have a CLI even though there is
also a scripting language under the hood. The reason for this is
simply that Python would make for a funny CLI -- you'd have to quote
arguments, etc.
* We would like to drop the existing GUI. It does not align with our
goals. However, as I said during the meeting, if someone wants to
maintain the GUI, that would be fine.
We may want a standalone debugger GUI. One idea is to see if we can
reuse the Eclipse work using RCP. Another idea is to go the gdb
route and hope some 3rd party either writes one, or ports and
existing one from gdb.
* Naming. There's some contention as to whether the result should
keep the name "Frysk". I will let proponents and opponents make
their arguments; I don't have an opinion on this.
* Process. We'd like to institute some form of patch review. Ideally
this would be low on bureaucracy; perhaps just an Apache-style "+1"
voting system. The intent here is to raise coding standards overall
-- make sure that features have more polish when they go in, and
that both internal and external documentation are included.
* Roadmap and milestones. We want to publish a general roadmap along
with milestones that will describe roughly what features will be
available when. I don't know whether this is interesting to non-Red
Hat folks; if not we can do this internally. Let us know.
The general milestone idea we've been discussing is "depth first" --
using user-visible features to drive the development process; but
probably the "releases" would be time-based as much as possible.
The roadmap will be where we figure out what "best C++ debugger"
means -- that is, what specific features this entails. We'll be
starting that process on this list (or elsewhere in public) soon.
* Licensing. We discussed this at the meeting. Eric is looking into
the ownership issue and the choice of license.
We've talked a bit about constraints on the license and owner:
* Who owns the current code; what do we need to drop or relicense if
we want to change the license
* Can we assign to the FSF or some other entity?
* What constraints does our Eclipse integration approach put on the
choice? Rick is looking into some details here.
* Can we reuse bits of gdb if we want? (There are a few things that
might be worth reusing.)
* GDB. A recurring question is: why not expend our efforts improving
gdb? There are no easy answers here; the tradeoffs are complicated.
This is probably more of a Red Hat internal decision (it is about
where we want to focus our efforts, not about the frysk project per
se) -- but it is an obvious and important question and deserves to
be brought up here.
We're open to arguments either way on this topic. Given our goals,
what would you choose to do?
That is pretty concise. I'm happy to try to expand on anything that
seems unclear -- goals, reasoning, etc.
I don't think I've forgotten anything here, but if I did, please bring
it up.
Since we want to build a healthy community around this project, your
opinion matters. Please share it. Aside from Red Hat's goals,
nothing here is truly decided; it is all open to debate.
thanks,
Tom
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Changes
2008-07-09 22:19 Changes Tom Tromey
@ 2008-07-10 0:06 ` Sami Wagiaalla
2008-07-11 17:04 ` Changes Sami Wagiaalla
2008-07-10 4:17 ` Changes Thiago Jung Bauermann
` (3 subsequent siblings)
4 siblings, 1 reply; 13+ messages in thread
From: Sami Wagiaalla @ 2008-07-10 0:06 UTC (permalink / raw)
To: tromey; +Cc: Frysk List
> * HPD. We discussed HPD a little. It seems ok, overall, though a bit
> underpowered; in particular there are common debugging operations
> that one can do in gdb which have no analog in HPD. So, we know we
> must at least extend it.
>
> Some people expressed concern that the HPD language differs
> needlessly from gdb -- meaning that they need to re-learn things to
> try a new debugger. I don't think we have a particular solution in
> mind for this. We could move more toward a gdb-like CLI, or we
> could supply a compatibility mode; dunno.
>
I think neither GDB nor the HPD spec should be taken literary we can use
them as a source of inspiration. HPD offers cool commands like focus
because it has considered the multi threaded, multi process problem. GDB
offers familiarity.
> * We would like to drop the existing GUI. It does not align with our
> goals. However, as I said during the meeting, if someone wants to
> maintain the GUI, that would be fine.
>
> We may want a standalone debugger GUI. One idea is to see if we can
> reuse the Eclipse work using RCP. Another idea is to go the gdb
> route and hope some 3rd party either writes one, or ports and
> existing one from gdb.
>
Having written a gui at once before has served the great purpose of
making sure that the design of the core is gui friendly. Things like
asynchronous requests, and top/bottom half event handling. So I think we
know what it takes to write a gui friendly core and we can get away with
not writing one for a while.
> * Naming. There's some contention as to whether the result should
> keep the name "Frysk". I will let proponents and opponents make
> their arguments; I don't have an opinion on this.
>
I vote -1 on this. The frysk brand is a good one and can now be made
even better. Adoppting a new one will make the frysk brand look bad, and
the new one look untrustworthy. Also, I think it is not needed as the
goals of the project have not changed in my opinion, but repriorities,
or better communicated. things like lots of threads lots of .so's have
been on our tongues for a while.
> * Process. We'd like to institute some form of patch review. Ideally
> this would be low on bureaucracy; perhaps just an Apache-style "+1"
> voting system. The intent here is to raise coding standards overall
> -- make sure that features have more polish when they go in, and
> that both internal and external documentation are included.
>
I am ambivalent about this, but i will vote +1 because i would like to
try it out and see if it improves ownership, and familiarity with parts
of the code other than what one is working on.
> * Roadmap and milestones. We want to publish a general roadmap along
> with milestones that will describe roughly what features will be
> available when. I don't know whether this is interesting to non-Red
> Hat folks; if not we can do this internally. Let us know.
>
We havent done it publicly before. Lets do it and see how it works out.
> The general milestone idea we've been discussing is "depth first" --
> using user-visible features to drive the development process; but
> probably the "releases" would be time-based as much as possible.
>
> The roadmap will be where we figure out what "best C++ debugger"
> means -- that is, what specific features this entails. We'll be
> starting that process on this list (or elsewhere in public) soon.
>
I am a fan of time based releases. If i was to run the project I would
give people 3 week assignments (or 3 months assignments that can be
broken into 3 week deliverables) and do a monthly release. At this point
however, as the project is accelerating from 0, i dont know what makes
sence. Maybe quarterly releases.
> * GDB. A recurring question is: why not expend our efforts improving
> gdb? There are no easy answers here; the tradeoffs are complicated.
>
> This is probably more of a Red Hat internal decision (it is about
> where we want to focus our efforts, not about the frysk project per
> se) -- but it is an obvious and important question and deserves to
> be brought up here.
>
> We're open to arguments either way on this topic. Given our goals,
> what would you choose to do?
>
I would choose to not work on GDB. I think it would be difficult to get
our patches upstream especially ones as radical as we will propose, and
rightly so. If you send a patch to gdb that implements a thread state
machine for example, how would gdb maintainers know what effect this has
on all the permutations of archetecutre, language, and executable
formats that gdb supports ?
Any points which I have not responded to I have no objects or comments on.
Sami
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Changes
2008-07-09 22:19 Changes Tom Tromey
2008-07-10 0:06 ` Changes Sami Wagiaalla
@ 2008-07-10 4:17 ` Thiago Jung Bauermann
2008-07-10 5:43 ` Changes Sami Wagiaalla
` (2 more replies)
2008-07-10 8:24 ` Changes Phil Muldoon
` (2 subsequent siblings)
4 siblings, 3 replies; 13+ messages in thread
From: Thiago Jung Bauermann @ 2008-07-10 4:17 UTC (permalink / raw)
To: Tom Tromey; +Cc: Frysk List
Hi,
My R$ 0,02 FWIW.
On Wed, 2008-07-09 at 16:18 -0600, Tom Tromey wrote:
> Here's the first message of the messages I promised during the
> meeting.
Thanks.
> * Integrate with Eclipse
The debugger being in C++, do you see this happening with an MI-like
interface?
> In particular I think Red Hat is not going to pursue Frysk's current
> monitoring and tracing goals, or the existing GUI.
Perhaps this can be left as a dormant goal, to be revisited when a
working solution is at hand?
A monitoring and tracing tool would be very useful.
> * Java. We've heard many times while discussing Frysk with other
> parties that the choice of Java is an odd one.
>
> In order to more fully align the interests of the developers of the
> debugger with the interests of its users, we'd like to use C++ as
> the implementation language. We picture refactoring the core of
> Frysk into C++; not changing the design but simply the
> implementation language.
Nice. IMHO, starting from scratch again in C++ would be just more work
at the end of the day... IMHO again the way to go is to reuse as much
code as possible, including from GDB. The idea is to take the shortest
path to a good working solution.
> * Scripting. One issue with gdb is its poor support for scripting.
> We think scripting is needed for debugger programmability, and in
> particular that it will be needed for C++ pretty-printing. So, our
> thinking is that this debugger would have a Python binding to its
> core.
I'm in favour of that.
I just think that poor support for scripting shouldn't be counted as a
weakness of GDB, since it is being addressed there as we speak (of
course you know that :-) ).
> In order to exercise this binding code, we picture rewriting the
> existing CLI code in Python. The idea here is that part of the CLI
> need a rewrite anyhow, and there is no particular reason that the
> CLI needs to be written in C++.
Nice idea.
> We think it makes sense to still have a CLI even though there is
> also a scripting language under the hood. The reason for this is
> simply that Python would make for a funny CLI -- you'd have to quote
> arguments, etc.
Agreed.
> * We would like to drop the existing GUI. It does not align with our
> goals. However, as I said during the meeting, if someone wants to
> maintain the GUI, that would be fine.
>
> We may want a standalone debugger GUI. One idea is to see if we can
> reuse the Eclipse work using RCP. Another idea is to go the gdb
> route and hope some 3rd party either writes one, or ports and
> existing one from gdb.
So having a GUI separate from Eclipse is within the goal of the project?
Just not the existing one? Sorry, I'm not sure I understood this part.
> * Process. We'd like to institute some form of patch review. Ideally
> this would be low on bureaucracy; perhaps just an Apache-style "+1"
> voting system. The intent here is to raise coding standards overall
> -- make sure that features have more polish when they go in, and
> that both internal and external documentation are included.
I like the idea of a patch review process, I agree it will be a benefit.
> * Roadmap and milestones. We want to publish a general roadmap along
> with milestones that will describe roughly what features will be
> available when. I don't know whether this is interesting to non-Red
> Hat folks; if not we can do this internally. Let us know.
Please, don't have internal milestones, and avoid as much as possible
having internal anything... This is a very important point in trying to
make this a community project and not just a Red Hat one.
I think it is important for non-Red Hat folks to know what Red Hat
people are working at, and what are your goals, even short term ones.
> The general milestone idea we've been discussing is "depth first" --
> using user-visible features to drive the development process; but
> probably the "releases" would be time-based as much as possible.
Sounds good.
> The roadmap will be where we figure out what "best C++ debugger"
> means -- that is, what specific features this entails. We'll be
> starting that process on this list (or elsewhere in public) soon.
Look forward to it.
> * Licensing. We discussed this at the meeting. Eric is looking into
> the ownership issue and the choice of license.
This is another very important point in trying to make this a community
project and not just a Red Hat one.
Having Red Hat own all the code is a big road block to community
participation.
> We've talked a bit about constraints on the license and owner:
>
> * Who owns the current code; what do we need to drop or relicense if
> we want to change the license
> * Can we assign to the FSF or some other entity?
That's an interesting option.
> * What constraints does our Eclipse integration approach put on the
> choice? Rick is looking into some details here.
> * Can we reuse bits of gdb if we want? (There are a few things that
> might be worth reusing.)
As I said, IMHO we should reuse bits of GDB, and the licensing choice
should not hinder it.
> * GDB. A recurring question is: why not expend our efforts improving
> gdb? There are no easy answers here; the tradeoffs are complicated.
>
> This is probably more of a Red Hat internal decision (it is about
> where we want to focus our efforts, not about the frysk project per
> se) -- but it is an obvious and important question and deserves to
> be brought up here.
>
> We're open to arguments either way on this topic. Given our goals,
> what would you choose to do?
Like I said in the meeting, I'd choose to improve GDB. Of course I'm
nowhere near experienced enough in GDB to evaluate all the risks and
difficulties with that, but from where I stand it is the option that
makes more sense from a technical standpoint, and that would give the
biggest bang for the buck. Again, I'm thinking in terms of the shortest
path to get to a good solution.
> Since we want to build a healthy community around this project, your
> opinion matters. Please share it. Aside from Red Hat's goals,
> nothing here is truly decided; it is all open to debate.
Great. That's nice to know.
--
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Changes
2008-07-10 4:17 ` Changes Thiago Jung Bauermann
@ 2008-07-10 5:43 ` Sami Wagiaalla
2008-07-10 13:14 ` Changes Rick Moseley
2008-07-10 19:43 ` Changes Dodji Seketeli
2008-07-11 16:55 ` Changes Tom Tromey
2 siblings, 1 reply; 13+ messages in thread
From: Sami Wagiaalla @ 2008-07-10 5:43 UTC (permalink / raw)
To: Thiago Jung Bauermann; +Cc: Tom Tromey, Frysk List
>> In particular I think Red Hat is not going to pursue Frysk's current
>> monitoring and tracing goals, or the existing GUI.
>
> Perhaps this can be left as a dormant goal, to be revisited when a
> working solution is at hand?
>
> A monitoring and tracing tool would be very useful.
>
Ditto. I will bring it up again when the time is right.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Changes
2008-07-09 22:19 Changes Tom Tromey
2008-07-10 0:06 ` Changes Sami Wagiaalla
2008-07-10 4:17 ` Changes Thiago Jung Bauermann
@ 2008-07-10 8:24 ` Phil Muldoon
2008-07-11 10:44 ` Changes Phil Muldoon
2008-07-17 7:51 ` Changes Jan Blunck
4 siblings, 0 replies; 13+ messages in thread
From: Phil Muldoon @ 2008-07-10 8:24 UTC (permalink / raw)
To: tromey; +Cc: Frysk List, overholt
Tom Tromey wrote:
Hi Tom,
> Here's the first message of the messages I promised during the
> meeting.
>
> Red Hat is revisiting its interest in Frysk. In particular, our goal
> is now:
>
> Build the best C++ debugger in the world.
>
I brought these up as off-the-cuff remarks in a previous conversation,
but I think they have some meaning as a guiding principles:
- must not mislead the user by presenting incorrect data;
- must not further erode the stability of the inferior;
- must not quiesce the inferior unless necessary.
I'm sure there are others. I think a set a common quality criteria would
be good principles to keep in mind.
Brought up in the meeting, but in email too: What are our
differentiators? There are several debuggers out there. How will this
one be better than the others? Will it do "stuff" better, will it do
"stuff" that the others don't?
> * Java. We've heard many times while discussing Frysk with other
> parties that the choice of Java is an odd one.
>
> In order to more fully align the interests of the developers of the
> debugger with the interests of its users, we'd like to use C++ as
> the implementation language. We picture refactoring the core of
> Frysk into C++; not changing the design but simply the
> implementation language.
>
Language choice is not a terribly compelling debate for me; I'll happily
use whatever language people reason for. However for completeness here
are my arguments for C++:
- it places the project in the same environment as C++ developers, their
pain is our pain;
- we will use our debugger to solve our own C++ problems;
- C++ acts as a common language to reimplement ideas for C, and from Java.
In particular, porting of existing patterns should not be so painful in
C++ from Java. I think there are many patterns in Frysk that are high
value and well worth porting.
> * Scripting. One issue with gdb is its poor support for scripting.
> We think scripting is needed for debugger programmability, and in
> particular that it will be needed for C++ pretty-printing. So, our
> thinking is that this debugger would have a Python binding to its
> core.
>
> In order to exercise this binding code, we picture rewriting the
> existing CLI code in Python. The idea here is that part of the CLI
> need a rewrite anyhow, and there is no particular reason that the
> CLI needs to be written in C++.
>
This is incredibly important, and should be a guiding goal from day one.
It should be clear and present in all our minds as we design this
debugger. I cannot see the days of a monolithic debugger with wire
protocols lasting too much longer. The maintenance and erosion of any
large code base are compelling stories in terms of cost.
If there is a particular reason for it, and the tools we create are
"present and well-designed", I think people will write their own layers
of utilities on top of our own. What better measure of success if people
use our scripting support to create their own tools?
> * We would like to drop the existing GUI. It does not align with our
> goals. However, as I said during the meeting, if someone wants to
> maintain the GUI, that would be fine.
>
Other than some small fixes that Rick has heroically being putting into
the UI, there has not been any serious work on it for over a year. It
was effectively de-staffed. I think this is a non-issue, it's been
dropped already.
> We may want a standalone debugger GUI. One idea is to see if we can
> reuse the Eclipse work using RCP. Another idea is to go the gdb
> route and hope some 3rd party either writes one, or ports and
> existing one from gdb.
>
For our first client, I really don't want a huge dependency chain that
may come with an Eclipse Rich Client Platform application. However, I
think an Eclipse IDE plug-in - hosted and developed on the Eclipse Linux
distribution project - is an essential element. I've CC'd Andrew
Overholt; I'd really value his opinion. But for my own 2 pence worth,
the IDE plug-in should really be integrating with DSDP-DD project
goals. GDB/MI is the only client of DSDP-DD that I have knowledge at the
moment, and that is driving the design. It shouldn't, we should ;)
Personally as an initial driver, I would much rather see existing
lightweight tools ported to work with our engine. I've spent the last
two weeks examining Nemiver; its back-end code is built for expansion to
other engines. As part of our outreach, we should engage developers of
existing tools and try to persuade them to develop with us.
> * Naming. There's some contention as to whether the result should
> keep the name "Frysk". I will let proponents and opponents make
> their arguments; I don't have an opinion on this.
I think we should start a new project, with a new name. It's been done
before. Frysk used to be called Accudog. Leave the Frysk base as it is,
and start a new project site. Maybe at Fedora Hosted. Or somewhere else.
The current name is saddled with previous release experiences, and
instability. If the new debugger is written from scratch with ideas
from Frysk, it''s not Frysk; it is something derived or based on Frysk
and GDB.
> * Process. We'd like to institute some form of patch review. Ideally
> this would be low on bureaucracy; perhaps just an Apache-style "+1"
> voting system. The intent here is to raise coding standards overall
> -- make sure that features have more polish when they go in, and
> that both internal and external documentation are included.
>
Good. Some ideas:
- no change should go into the base without at least one person seeing it;
- no refactor should ever happen as an imposition of one will over another.;
- good humour, in an environment of learning.
This project is far too big and complex for one brain; we will all be
deeply novice in many areas, while being expert in others. I look
forward to this discussion.
> * Roadmap and milestones. We want to publish a general roadmap along
> with milestones that will describe roughly what features will be
> available when. I don't know whether this is interesting to non-Red
> Hat folks; if not we can do this internally. Let us know.
>
I think a release roadmap is compelling to the project. No reason for
one company to have one roadmap and another have theirs. Lets see if the
people on the project now, across all the companies can come up with a
mutual document. This gives list-lurkers a chance to show-up and be seen ;)
> * GDB. A recurring question is: why not expend our efforts improving
> gdb? There are no easy answers here; the tradeoffs are complicated.
>
> This is probably more of a Red Hat internal decision (it is about
> where we want to focus our efforts, not about the frysk project per
> se) -- but it is an obvious and important question and deserves to
> be brought up here.
>
> We're open to arguments either way on this topic. Given our goals,
> what would you choose to do?
I've talked in this email about ideas regarding a new debugger, so my
ideas are pretty transparent here. I'll tackle the GDB question in
another separate email.
Regards
Phil
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Changes
2008-07-10 5:43 ` Changes Sami Wagiaalla
@ 2008-07-10 13:14 ` Rick Moseley
2008-07-10 13:26 ` Changes Phil Muldoon
2008-07-10 17:07 ` Changes Eric Bachalo
0 siblings, 2 replies; 13+ messages in thread
From: Rick Moseley @ 2008-07-10 13:14 UTC (permalink / raw)
To: frysk
Sami Wagiaalla wrote:
>
>>> In particular I think Red Hat is not going to pursue Frysk's current
>>> monitoring and tracing goals, or the existing GUI.
>>
>> Perhaps this can be left as a dormant goal, to be revisited when a
>> working solution is at hand?
>>
>> A monitoring and tracing tool would be very useful.
>>
>
> Ditto. I will bring it up again when the time is right.
>
>
Agreed too. The ability to catch a task as it is abnormally terminating
and bring up the debugger is a powerful thing IMHO. I don't see any
need here to involve another app(Systemtap has been mentioned) to
perform this feature. I don't remember this being too difficult in
Frysk(although I am not the one that implemented it.)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Changes
2008-07-10 13:14 ` Changes Rick Moseley
@ 2008-07-10 13:26 ` Phil Muldoon
2008-07-10 17:07 ` Changes Eric Bachalo
1 sibling, 0 replies; 13+ messages in thread
From: Phil Muldoon @ 2008-07-10 13:26 UTC (permalink / raw)
To: Rick Moseley; +Cc: frysk
Rick Moseley wrote:
>>
>> Ditto. I will bring it up again when the time is right.
>>
>>
> Agreed too. The ability to catch a task as it is abnormally
> terminating and bring up the debugger is a powerful thing IMHO. I
> don't see any need here to involve another app(Systemtap has been
> mentioned) to perform this feature. I don't remember this being too
> difficult in Frysk(although I am not the one that implemented it.)
>
The (three) Frysk state machines are what catches that, and that is a
considerable amount of complex code. Modelling a thread is delicate,
complex and very fuzzy. Take a look at LinuxWaitBuilder and how it has
to do backflips to catch out of order wait notifications. But I think
the issue is not catching a thread as it spawns another - we will have
to have that. That's in the goals. Follow fork, follow clone - these
are a intrinsic to the scalability goal of working with many threads
(imho ;))
It's all the other always-on, low-cost monitoring goals that Systemtap
do now I think are being excluded.
Regards
Phil
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Changes
2008-07-10 13:14 ` Changes Rick Moseley
2008-07-10 13:26 ` Changes Phil Muldoon
@ 2008-07-10 17:07 ` Eric Bachalo
1 sibling, 0 replies; 13+ messages in thread
From: Eric Bachalo @ 2008-07-10 17:07 UTC (permalink / raw)
To: Rick Moseley; +Cc: frysk
Rick Moseley wrote:
> Sami Wagiaalla wrote:
>>
>>>> In particular I think Red Hat is not going to pursue Frysk's current
>>>> monitoring and tracing goals, or the existing GUI.
>>>
>>> Perhaps this can be left as a dormant goal, to be revisited when a
>>> working solution is at hand?
>>>
>>> A monitoring and tracing tool would be very useful.
>>>
>>
>> Ditto. I will bring it up again when the time is right.
>>
>>
> Agreed too. The ability to catch a task as it is abnormally terminating
> and bring up the debugger is a powerful thing IMHO. I don't see any
> need here to involve another app(Systemtap has been mentioned) to
> perform this feature. I don't remember this being too difficult in
> Frysk(although I am not the one that implemented it.)
The tracing features is an area I would like to investigate when we look
at making frysk and systemtap work closely together. But I want to see
a robust debugging app working first.
I would also like to see investigation into using systemtap or using
same interface to OS that systemtap uses, or using prebuilt tapsets, to
implement fast and efficient conditional breakpoints / watchpoints /
catchpoints.
- Eric
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Changes
2008-07-10 4:17 ` Changes Thiago Jung Bauermann
2008-07-10 5:43 ` Changes Sami Wagiaalla
@ 2008-07-10 19:43 ` Dodji Seketeli
2008-07-11 16:55 ` Changes Tom Tromey
2 siblings, 0 replies; 13+ messages in thread
From: Dodji Seketeli @ 2008-07-10 19:43 UTC (permalink / raw)
To: Thiago Jung Bauermann; +Cc: Tom Tromey, Frysk List
Thiago Jung Bauermann a écrit :
[...]
>
>> * Integrate with Eclipse
>
> The debugger being in C++, do you see this happening with an MI-like
> interface?
>
I'd think that starting off with the debugging engine being alone in its
own process can be something good for many reasons:
1/being in one coherent language, whatever the language is. If the
language is c/c++ that eases debugging during developments thanks to
tools like valgrind etc ...
2/shield the user interface against wierd things like signal based
interactions that can happen between the debugging engine and the
inferior process being debugged.
3/gives a chance to the UI process to be single threaded, using
mainloops like the glib mainloop or the Qt mainloop to come up with non
blocking UIs and still being asynchronously notified about state
changes in the remote debugging engine process.
This scenario requires a wire protocol. It's not obliged to be GDB/MI,
though.
[...]
>
> Nice. IMHO, starting from scratch again in C++ would be just more work
> at the end of the day... IMHO again the way to go is to reuse as much
> code as possible, including from GDB. The idea is to take the shortest
> path to a good working solution.
>
Exactly. That's also why having the debugger in C/C++ can be
interesting. It eases code sharing with GDB. Much more than if we need
to write (and debug) bindings each time we want to use a C function
coming from outside.
[...]
>
> So having a GUI separate from Eclipse is within the goal of the project?
> Just not the existing one? Sorry, I'm not sure I understood this part.
>
I'd think that if the APIs UI <-> debugging engine are well defined and
nice, debugger UIs including ad hoc tools built by other project to
debug particular scenarii we don't even know about today will be likely
to flourish.
>> * Process. We'd like to institute some form of patch review. Ideally
>> this would be low on bureaucracy; perhaps just an Apache-style "+1"
>> voting system. The intent here is to raise coding standards overall
>> -- make sure that features have more polish when they go in, and
>> that both internal and external documentation are included.
>
> I like the idea of a patch review process, I agree it will be a benefit.
Yes, I like that as well.
If we stick to git - I love git - I think it could be nice do something
like what the X.org project did. Potential contributors foo could be
given write access to sourceware.org/users/foo so that they can slam
their own branches in there. They'd then post urls to the commits (in
their branches) they want to see pushed to the official tree and wait
for reviewers approval. Of course that wouldn't remove the possibility
to send patches to the list directly.
My 2 euro cents.
Cheers,
Dodji.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Changes
2008-07-09 22:19 Changes Tom Tromey
` (2 preceding siblings ...)
2008-07-10 8:24 ` Changes Phil Muldoon
@ 2008-07-11 10:44 ` Phil Muldoon
2008-07-17 7:51 ` Changes Jan Blunck
4 siblings, 0 replies; 13+ messages in thread
From: Phil Muldoon @ 2008-07-11 10:44 UTC (permalink / raw)
To: tromey; +Cc: Frysk List
Tom Tromey wrote:
> * GDB. A recurring question is: why not expend our efforts improving
> gdb? There are no easy answers here; the tradeoffs are complicated.
>
> This is probably more of a Red Hat internal decision (it is about
> where we want to focus our efforts, not about the frysk project per
> se) -- but it is an obvious and important question and deserves to
> be brought up here.
>
> We're open to arguments either way on this topic. Given our goals,
> what would you choose to do
My 2 euros on why a new project is a viable.
GDB is a cool project. No doubt. It has remained relevant for years, and
still does today. It has maintained the status as the best open-source
debugger - free as in beer and speech through that time. And despite
many pretenders and competitors it continues to remain as the best and
most viable. It attracts the brightest minds, and generates sometime
intense controversy; it has been described as a work of art and, well,
other things not so nicely put. GDB is great because of ALL the people
that work on it, past and present. How many visionaries, engineers,
testers and documenters have poured effort into it over the years? Often
silently, sometimes not ;)
But despite this sum effort, and the momentum, I still think there is
room for a new project. Because I seem them as complimentary. I do not
subscribe to the division-of-labour and mutual-exclusion theories in
free software. Granted, in an ideal world we should all work on one
piece of software, to fulfil one concrete goal. But we do not do that,
it seems. It is clearly evident through many projects: GNOME and KDE,
Emacs and VIM, Eclipse and Netbeans, and so on. I find this compelling
behaviour; look at the multitude of window managers that one can use
with the desktop. And what we lose in division-of-labour, we gain in a a
more vibrant community. But this is a deeper problem for debuggers, I
think. Software is a complex. Debuggers perhaps among the most complex
and challenging to write. Nobody wants a buggy debugger: the engineer
who has reached for it is already frustrated. We do not need to add to
the sum of that. And heaven help us if we further erode the stability of
the inferior beyond the state it was in when we were called. We need
more people in the open-source debugging world.
So with that being said, I do not think the "new debugger" and GDB
should exist in a vacuum. And as long as the licenses are compatible
(and I see no reason why they should not be), we should borrow, fix,
back-port and submit patches from each others software.
GDB does not do C++ well. I do not like being negative, but it just
doesn't. I am not terribly sure why, though I have tried to find out.
Maybe the problem is that it has been added over time, to an engine that
in not OOP aware? How do we solve that? I think we solve it by writing
another scriptable debugger in a research like environment. Once we
figure out why, there is no reason why we can then present the case to
the GDB community. And similarly, GDB has a very powerful urge to remain
as stable as possible. Stability over change. I do not think it is
cost-efficient to be answering research question in a release
environment, or in a product that has a powerful and strong promise of
stability to a community. On that note, I would invite the GDB people to
use this new promise of a project as a proving ground for technology.
Mature it here, then port it. If we do our homework right, we can make
cross-pollination as easy (or as hard, if we are sloppy) as possible.
Regards
Phil Muldoon
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Changes
2008-07-10 4:17 ` Changes Thiago Jung Bauermann
2008-07-10 5:43 ` Changes Sami Wagiaalla
2008-07-10 19:43 ` Changes Dodji Seketeli
@ 2008-07-11 16:55 ` Tom Tromey
2 siblings, 0 replies; 13+ messages in thread
From: Tom Tromey @ 2008-07-11 16:55 UTC (permalink / raw)
To: Thiago Jung Bauermann; +Cc: Frysk List
>>>>> "Thiago" == Thiago Jung Bauermann <bauerman@br.ibm.com> writes:
Tom> In particular I think Red Hat is not going to pursue Frysk's current
Tom> monitoring and tracing goals, or the existing GUI.
Thiago> Perhaps this can be left as a dormant goal, to be revisited when a
Thiago> working solution is at hand?
It is fine by me. If someone wants to pick this up right away, that
is also fine -- this part was just more a statement of Red Hat's goals.
I am not sure that there is any infrastructure that would be useful to
a tracing task that would not also be useful to a debugger. So, in
terms of the core, I could not think of anything that would need to be
different. (If you know of something here, I'd like to hear it.)
So, this is more about what deliverables Red Hat wants, and what parts
of the tool Red Hat plans to work on.
Thiago> Nice. IMHO, starting from scratch again in C++ would be just more work
Thiago> at the end of the day... IMHO again the way to go is to reuse as much
Thiago> code as possible, including from GDB. The idea is to take the shortest
Thiago> path to a good working solution.
This particular decision has been bothering me all week. And, I don't
really have an answer, or even a good process to arrive at an answer :(
I'll address that more in the roadmap email.
Tom> We may want a standalone debugger GUI. One idea is to see if we can
Tom> reuse the Eclipse work using RCP. Another idea is to go the gdb
Tom> route and hope some 3rd party either writes one, or ports and
Tom> existing one from gdb.
Thiago> So having a GUI separate from Eclipse is within the goal of
Thiago> the project? Just not the existing one? Sorry, I'm not sure I
Thiago> understood this part.
Yeah, sorry. It is confusing.
The current GUI does not align with our goals.
Red Hat may at some point want a standalone classic debugger GUI.
However, it isn't totally decided. I probably should have simply left
this off the list.
Tom
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Changes
2008-07-10 0:06 ` Changes Sami Wagiaalla
@ 2008-07-11 17:04 ` Sami Wagiaalla
0 siblings, 0 replies; 13+ messages in thread
From: Sami Wagiaalla @ 2008-07-11 17:04 UTC (permalink / raw)
To: tromey; +Cc: Frysk List
>> * GDB. A recurring question is: why not expend our efforts improving
>> gdb? There are no easy answers here; the tradeoffs are complicated.
>>
>> This is probably more of a Red Hat internal decision (it is about
>> where we want to focus our efforts, not about the frysk project per
>> se) -- but it is an obvious and important question and deserves to
>> be brought up here.
>>
>> We're open to arguments either way on this topic. Given our goals,
>> what would you choose to do?
>>
>
> I would choose to not work on GDB. I think it would be difficult to get
> our patches upstream especially ones as radical as we will propose, and
> rightly so. If you send a patch to gdb that implements a thread state
> machine for example, how would gdb maintainers know what effect this has
> on all the permutations of archetecutre, language, and executable
> formats that gdb supports ?
>
> Any points which I have not responded to I have no objects or comments on.
>
I want to add that I think that even if we work against the current and
get a solution in a close time line. I dont think that we can achieve
our extensibility goals our architectural design as I understand is
completely different and achieves extensibility well.
I also want to say that we should reuse whatever code we can from gdb
that is stable and mature and can be used as a black box. For example
while visualizing c++ data structures is an open ended problem, there
arnt many ways you can revolutionize unwinding. So even if the code is
ugly but doesn't need to be extended nor debugged go for it.
Sami
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Changes
2008-07-09 22:19 Changes Tom Tromey
` (3 preceding siblings ...)
2008-07-11 10:44 ` Changes Phil Muldoon
@ 2008-07-17 7:51 ` Jan Blunck
4 siblings, 0 replies; 13+ messages in thread
From: Jan Blunck @ 2008-07-17 7:51 UTC (permalink / raw)
To: Tom Tromey; +Cc: Frysk List
On Wed, Jul 09, Tom Tromey wrote:
> * Scripting. One issue with gdb is its poor support for scripting.
> We think scripting is needed for debugger programmability, and in
> particular that it will be needed for C++ pretty-printing. So, our
> thinking is that this debugger would have a Python binding to its
> core.
>
> In order to exercise this binding code, we picture rewriting the
> existing CLI code in Python. The idea here is that part of the CLI
> need a rewrite anyhow, and there is no particular reason that the
> CLI needs to be written in C++.
I find it somehow unnatural that the scripting capabilities are based on
python while the target language is C/C++.
From my point of view it would make sense to use a language similar to C, e.g.
like SIAL. Or at least provide the scripting capabilities as plugins.
Cheers,
Jan
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2008-07-17 7:51 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-07-09 22:19 Changes Tom Tromey
2008-07-10 0:06 ` Changes Sami Wagiaalla
2008-07-11 17:04 ` Changes Sami Wagiaalla
2008-07-10 4:17 ` Changes Thiago Jung Bauermann
2008-07-10 5:43 ` Changes Sami Wagiaalla
2008-07-10 13:14 ` Changes Rick Moseley
2008-07-10 13:26 ` Changes Phil Muldoon
2008-07-10 17:07 ` Changes Eric Bachalo
2008-07-10 19:43 ` Changes Dodji Seketeli
2008-07-11 16:55 ` Changes Tom Tromey
2008-07-10 8:24 ` Changes Phil Muldoon
2008-07-11 10:44 ` Changes Phil Muldoon
2008-07-17 7:51 ` Changes Jan Blunck
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).