public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
* 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).