public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
* Roadmap beginnings
@ 2008-07-11 19:53 Tom Tromey
  2008-07-11 20:56 ` Jan Kratochvil
                   ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Tom Tromey @ 2008-07-11 19:53 UTC (permalink / raw)
  To: Frysk List

I want to start discussion about the roadmap now, even before we've
resolved a few major questions.  Initially I was hoping to defer this
until we'd dug into the gdb question a bit, and settled the various
licensing issues.  However, email yesterday from Keith showed me that
these aren't independent -- some choices we make here may affect the
outcome of those other decisions.  (More on this below.)


So, what does "best C++ debugger" mean?  Naturally, I don't have a
full list.  But, I have start -- please help add to this.


The baseline is gdb doing native debugging of a C program.  I think it
doesn't make sense to do anything less than this.  This covers the
usual stuff: breakpoints, watchpoints, step, next, print.


There's a bunch of specific C++-debugging things that, afaik, gdb does
not do very well:

* Correct expression parsing.  (Though I am told this is extremely
  difficult to impossible in the general case.)

* Nice user experience when debugging with exceptions.  E.g., if you
  'next' over a function call, and the function throws an exception to
  a "higher" frame, the program should stop there.

* Pretty-printing of STL containers and other C++ objects.

* Smarter demangling of names.  The ideal would be that demangling
  yields the name that the user wrote in the source -- meaning,
  compressing the output by omitting default arguments, and respecting
  typedefs.


Scalability appears twice on the requirements list -- scaling to large
programs and scaling to many threads.  The latter is addressed, I
think, by the non-stop debugging design already in frysk (and being
added to gdb).  I am not sure precisely what problems gdb has with the
former; however I am told there is a BFD scalability issue when moving
to multiple processes.


There are a few concerns folks have raised about what does not appear
in the goal -- for example, cross debugging, or support for multiple
languages, or remote debugging.  While I think these things aren't
directly on our wish-list, I think these sorts of things can be
addressed with good design.  We don't want to shoot ourselves in the
foot.

One possible exception here is that, AFAIK, Red Hat only cares about
ELF targets.


Connecting to a GUI is turning out to be a driver for some decisions.
I have heard some dissatisfaction expressed about MI.  There seem to
be two schools of thought: (1) use some wire protocol to separate the
GUI from the debugger, or (2) use a library.

#1 is pretty much understood, I think.  Setting aside specific
complaints about MI, a possible drawback I have heard is that this
increases latency for debugging operations.  I haven't seen any
measurements of this, though.

#2 has several nice qualities, which I won't enumerate here.  In order
to behave sanely as a library, the debugger does require a nicer
kernel API than ptrace+wait; but this is being worked on already.

However, this approach does put more constraints on the licensing.  In
particular, GPLv3 would be a bad choice, as (I believe, IANAL) it
would prevent library use in Eclipse.

This in turn would impact our ability to reuse code from gdb.  I have
had my eye on a couple gdb modules as good candidates for reuse: the
macro expansion code, and perhaps the disassemblers.  (I'm not a gdb
expert; if you know of other modular, reusable bits, I'd like to hear
about them.)

Also, if #2 is a strong requirement -- if we really believe that #1 is
a non-starter -- then that would essentially rule out working on gdb.
I say this based on my belief that gdb is not a good candidate for
librarification.

This decision is not as simple as it may seem.  For example, it would
likely restrict what "intelligence" we could put in to the CLI, as (I
imagine) the library users would largely bypass the CLI in favor of
direct API access.


As I mentioned in the earlier note, we want to provide scripting
support based on Python.  From our perspective, Python is the best
choice because it is popular and generally acceptable.


I think if we achieve all of the above, we will have made a solid C++
debugger.  For it to be "best in the world" I think we will need to
raise the bar a bit.  A few ideas I've heard kicked around:

* Reverse-time debugging.  (There are some gdb patches for this.)

* "Smart" multi-process debugging, whatever that means.  The blue sky
  idea I have heard here is to be able to step into a remote procedure
  call and start debugging the other side.  (It isn't clear to me that
  the implementation effort here is worth the payoff.)

* Multi-language debugging where one of the languages is a scripting
  language.  Offhand it seems to me that this is largely a CLI issue
  -- filtering stack traces, rewriting expressions to look into
  interpreter data structures, avoiding a direct 1:1 mapping between a
  user's notation for a {break,watch}-point and the internal objects
  that this creates, etc.

  This one really has nothing to do with C++ per se.

* Some kind of systemtap integration, as Eric has asked for.  I'm
  still very unclear on what this would look like.

* The ability to debug a program being run under valgrind.  This is
  mildly related to the debugging-a-scripting-language question, but
  also (I imagine) probably requires changes on the valgrind end.

* Fix-and-continue.  (Though this appears to be something that sounds
  cooler than it actually is.)

It is kind of unfair of me to hold out the blue-sky stuff, since I
think we will have our hands full on just the essentials.  But, I
wanted to get people thinking about this a bit more.  Also, some of
these have come up repeatedly during our internal discussions.


It would also be worth doing a bit of competitive analysis of the
leading closed-source debuggers out there.

Tom

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Roadmap beginnings
  2008-07-11 19:53 Roadmap beginnings Tom Tromey
@ 2008-07-11 20:56 ` Jan Kratochvil
  2008-07-11 21:37   ` Tom Tromey
  2008-07-11 23:11   ` Kris Van Hees
  2008-07-11 21:53 ` Daniel Jacobowitz
  2008-07-11 22:48 ` Roadmap beginnings Phil Muldoon
  2 siblings, 2 replies; 19+ messages in thread
From: Jan Kratochvil @ 2008-07-11 20:56 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Frysk List

Hi,

while IMO definitely not much important right now but

On Fri, 11 Jul 2008 21:53:28 +0200, Tom Tromey wrote:
> As I mentioned in the earlier note, we want to provide scripting
> support

(dot)

> based on Python.  From our perspective, Python is the best
> choice because it is popular and generally acceptable.

This is already your personal bias, it may be worth to design the scripting
support easy enough to add more language bindings there (such as Perl XS).
(I do not track your GDB patches to say more about them.)


Best Regards,
Jan

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Roadmap beginnings
  2008-07-11 20:56 ` Jan Kratochvil
@ 2008-07-11 21:37   ` Tom Tromey
  2008-07-11 21:54     ` Daniel Jacobowitz
  2008-07-11 23:11   ` Kris Van Hees
  1 sibling, 1 reply; 19+ messages in thread
From: Tom Tromey @ 2008-07-11 21:37 UTC (permalink / raw)
  To: Jan Kratochvil; +Cc: Frysk List

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Thanks for sending this to the list.
Open critique is important.

Tom> based on Python.  From our perspective, Python is the best
Tom> choice because it is popular and generally acceptable.

Jan> This is already your personal bias, it may be worth to design the
Jan> scripting support easy enough to add more language bindings there
Jan> (such as Perl XS).  (I do not track your GDB patches to say more
Jan> about them.)

Yeah.  This is my bias -- though FWIW I personally am not a big Python
fan.

There are two parts to this idea: one scripting language, and the
particular choice.

Why one language?  I think the most important reason to prefer a
single scripting language is that this enables an ecosystem of useful
scripts.

Why Python?  Python is popular at Red Hat and beyond, and is more or
less a critical part of the distro.  I think it is fair to describe it
as the de facto default scripting language choice at Red Hat.

Finally, I think projects that try to be scripting-language-neutral
often fail to be good at any of them.


Kinda OT, but: the choice of Python for gdb has more or less the same
rationale; but there I didn't pick it -- I just picked up Volodya's
initial code, and I think he followed the outcome of a discussion on
the gdb list in early 2007.

Tom

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Roadmap beginnings
  2008-07-11 19:53 Roadmap beginnings Tom Tromey
  2008-07-11 20:56 ` Jan Kratochvil
@ 2008-07-11 21:53 ` Daniel Jacobowitz
  2008-07-14 16:34   ` Tom Tromey
  2008-07-22 20:29   ` Debugger Work (Was: Roadmap beginnings) Tom Tromey
  2008-07-11 22:48 ` Roadmap beginnings Phil Muldoon
  2 siblings, 2 replies; 19+ messages in thread
From: Daniel Jacobowitz @ 2008-07-11 21:53 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Frysk List

On Fri, Jul 11, 2008 at 01:53:28PM -0600, Tom Tromey wrote:
> So, what does "best C++ debugger" mean?  Naturally, I don't have a
> full list.  But, I have start -- please help add to this.

Thanks for posting this - I think it's an enlightening question.
Let me categorize these briefly:

> There's a bunch of specific C++-debugging things that, afaik, gdb does
> not do very well:
> 
> * Correct expression parsing.  (Though I am told this is extremely
>   difficult to impossible in the general case.)

It does a not half bad job, and specific problems with it are fixable.
As for ultimate correctness and completeness, I have serious doubts
that it is feasible - and I also doubt it would see enough use to
justify the enormous investment.  Prove me wrong and we'll merge it :-)

> * Nice user experience when debugging with exceptions.  E.g., if you
>   'next' over a function call, and the function throws an exception to
>   a "higher" frame, the program should stop there.

I'd call this a small project; only weeks of work to fix.

> * Pretty-printing of STL containers and other C++ objects.

This is a bigger project, but as Tom certainly knows GDB is solving it
already.

> * Smarter demangling of names.  The ideal would be that demangling
>   yields the name that the user wrote in the source -- meaning,
>   compressing the output by omitting default arguments, and respecting
>   typedefs.

Small, maybe midsized GDB project; dependent on a larger project in
the compiler to generate useful information.  This is a recurring
theme; GCC's symbolic debug info is not adequate.

Anyway, the trend I wanted to demonstrate: these are straightforward
incremental additions to GDB.  I'll sit back now and see what else
comes up in the discussion, and if any of it has a fundamentally
different character.  I'm not convinced that it will or that it won't.

> One possible exception here is that, AFAIK, Red Hat only cares about
> ELF targets.

As Ian said in his talk, ELF is a wonderful format used by almost all
of maybe 5% of programs.  If you're going to be ELF-centric, you lose
Windows and OS X native debugging - and that's a big user base, even
if not directly RH customers.  So (stating the obvious here, I know)
keep some kind of abstraction layer on file formats, even if it makes
other things look like ELF :-)

> #1 is pretty much understood, I think.  Setting aside specific
> complaints about MI, a possible drawback I have heard is that this
> increases latency for debugging operations.  I haven't seen any
> measurements of this, though.

There is a lot of room to optimize the existing performance of GDB/MI
(and other GUI-reaction-time sensitive areas of GDB), plus the
protocol is generally pipelining-friendly.  Without numbers, I find
this hard to credit.

I've seen people hold CDT up as an example of this problem.  I'm not
personally involved with Eclipse development, but my understanding
from others is that CDT is slow because CDT is slow, not because MI is
slow.  DSF is expected to be much faster.

> * The ability to debug a program being run under valgrind.  This is
>   mildly related to the debugging-a-scripting-language question, but
>   also (I imagine) probably requires changes on the valgrind end.

I think it has little or nothing to do with the debugger; the easiest
implementation would be a remote protocol implementation in valgrind.

> It would also be worth doing a bit of competitive analysis of the
> leading closed-source debuggers out there.

I haven't done this, but my expectation is that more of the
differentiation is in the GUI capabilities than the back end
capabilities.  If you want to talk about a modern, open-source, widely
developer accessible debugger, I think you need to consider GDB +
Eclipse as a combination, not GDB alone.  You can argue about what
goes after the plus sign.

-- 
Daniel Jacobowitz
CodeSourcery

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Roadmap beginnings
  2008-07-11 21:37   ` Tom Tromey
@ 2008-07-11 21:54     ` Daniel Jacobowitz
  0 siblings, 0 replies; 19+ messages in thread
From: Daniel Jacobowitz @ 2008-07-11 21:54 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Jan Kratochvil, Frysk List

On Fri, Jul 11, 2008 at 03:36:22PM -0600, Tom Tromey wrote:
> Kinda OT, but: the choice of Python for gdb has more or less the same
> rationale; but there I didn't pick it -- I just picked up Volodya's
> initial code, and I think he followed the outcome of a discussion on
> the gdb list in early 2007.

Yes, that's correct.  A wide gamut of programming languages were
suggested (my original prototype used Guile), but we settled on Python
in order to have a single standard language with a substantial user
base.

-- 
Daniel Jacobowitz
CodeSourcery

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Roadmap beginnings
  2008-07-11 19:53 Roadmap beginnings Tom Tromey
  2008-07-11 20:56 ` Jan Kratochvil
  2008-07-11 21:53 ` Daniel Jacobowitz
@ 2008-07-11 22:48 ` Phil Muldoon
  2 siblings, 0 replies; 19+ messages in thread
From: Phil Muldoon @ 2008-07-11 22:48 UTC (permalink / raw)
  To: tromey; +Cc: Frysk List

Tom Tromey wrote:
> I want to start discussion about the roadmap now, even before we've
> resolved a few major questions.  Initially I was hoping to defer this
> until we'd dug into the gdb question a bit, and settled the various
> licensing issues.  However, email yesterday from Keith showed me that
> these aren't independent -- some choices we make here may affect the
> outcome of those other decisions.  (More on this below.)
>   

I must admit to difficulties in reconciling this email chain with the 
"Changes" email chain, especially as I don't think the "Changes" email 
is done yet. I kind of wish the roadmap discussion had not so much focus 
on: "GDB or not to be GDB". But if this is the way of things, then so be 
it. I do feel like I am rewriting the same email over and over, but in 
different ways. Sorry to sound a bit frustrated here.

> So, what does "best C++ debugger" mean?  Naturally, I don't have a
> full list.  But, I have start -- please help add to this.
>   

Scripting. If a modern debugger cannot support this then it will just be 
a reimplementation of a monolithic debugger + wire protocol. We already 
have one of those, and I've already written many words on the pros and 
cons. Can we make GDB scriptable? If we can, how much work is it.? Ditto 
for Frysk.

> There are a few concerns folks have raised about what does not appear
> in the goal -- for example, cross debugging, or support for multiple
> languages, or remote debugging.  While I think these things aren't
> directly on our wish-list, I think these sorts of things can be
> addressed with good design.  We don't want to shoot ourselves in the
> foot.
>
> One possible exception here is that, AFAIK, Red Hat only cares about
> ELF targets.
>   

Yes, agreed.

> #1 is pretty much understood, I think.  Setting aside specific
> complaints about MI, a possible drawback I have heard is that this
> increases latency for debugging operations.  I haven't seen any
> measurements of this, though.
>   

There are huge, well documented debates on out-of-process/in-process 
debugging and wire-protocols. I will not trot them out here except 
mention that even the best, most efficient, wire protocol will be 
working out of band.

> #2 has several nice qualities, which I won't enumerate here.  In order
> to behave sanely as a library, the debugger does require a nicer
> kernel API than ptrace+wait; but this is being worked on already.
>
> However, this approach does put more constraints on the licensing.  In
> particular, GPLv3 would be a bad choice, as (I believe, IANAL) it
> would prevent library use in Eclipse.
>
> This in turn would impact our ability to reuse code from gdb.  I have
> had my eye on a couple gdb modules as good candidates for reuse: the
> macro expansion code, and perhaps the disassemblers.  (I'm not a gdb
> expert; if you know of other modular, reusable bits, I'd like to hear
> about them.)
>   

I'll be perfectly blunt here. If a less-free license is beginning to 
impinge upon the desirability of a "more-free" license we wish to use, 
lets should stop and think.

> Also, if #2 is a strong requirement -- if we really believe that #1 is
> a non-starter -- then that would essentially rule out working on gdb.
> I say this based on my belief that gdb is not a good candidate for
> librarification.
>   

#2 is (of course, imo) the prime reason for this project. I believe 
scripting requires an api/library approach, but would be happy to be 
proven otherwise ;)

Regards

Phil

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Roadmap beginnings
  2008-07-11 20:56 ` Jan Kratochvil
  2008-07-11 21:37   ` Tom Tromey
@ 2008-07-11 23:11   ` Kris Van Hees
  1 sibling, 0 replies; 19+ messages in thread
From: Kris Van Hees @ 2008-07-11 23:11 UTC (permalink / raw)
  To: Jan Kratochvil; +Cc: Tom Tromey, Frysk List

On Fri, Jul 11, 2008 at 10:55:31PM +0200, Jan Kratochvil wrote:
> Hi,
> 
> while IMO definitely not much important right now but
> 
> On Fri, 11 Jul 2008 21:53:28 +0200, Tom Tromey wrote:
> > As I mentioned in the earlier note, we want to provide scripting
> > support
> 
> (dot)
> 
> > based on Python.  From our perspective, Python is the best
> > choice because it is popular and generally acceptable.
> 
> This is already your personal bias, it may be worth to design the scripting
> support easy enough to add more language bindings there (such as Perl XS).
> (I do not track your GDB patches to say more about them.)

I would expect that any even vaguely successful implementation would be
sufficiently api/library based that scripting language support us a matter
of proving the correct bindings.  I.e. pretty much any scripting language
should be possible.  Any attempt to tie it to a specific scripting language
is likely to allow implementation details to bleed into the core, which
would be a major limitation.

So, perhaps we should primarily focus on the actual debugging core?  That
doesn't exclude the use of a specific chosen language to provide at least
a prototype of an interface to interact with the core for testing purposes
(and possibly later on as a more production-level interface), but we should
be very careful not to introduce strong ties that can prove to be a major
limitation later on.

	Kris

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Roadmap beginnings
  2008-07-11 21:53 ` Daniel Jacobowitz
@ 2008-07-14 16:34   ` Tom Tromey
  2008-07-14 16:45     ` Daniel Jacobowitz
  2008-07-14 17:19     ` Ian Lance Taylor
  2008-07-22 20:29   ` Debugger Work (Was: Roadmap beginnings) Tom Tromey
  1 sibling, 2 replies; 19+ messages in thread
From: Tom Tromey @ 2008-07-14 16:34 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: Frysk List

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

Thanks for your reply.

Tom> * Correct expression parsing.  (Though I am told this is extremely
Tom> difficult to impossible in the general case.)

Daniel> It does a not half bad job, and specific problems with it are fixable.
Daniel> As for ultimate correctness and completeness, I have serious doubts
Daniel> that it is feasible - and I also doubt it would see enough use to
Daniel> justify the enormous investment.  Prove me wrong and we'll merge it :-)

:).  I'm looking around a bit to see if I can find specifics of what
is wrong.

Daniel> Anyway, the trend I wanted to demonstrate: these are straightforward
Daniel> incremental additions to GDB.  I'll sit back now and see what else
Daniel> comes up in the discussion, and if any of it has a fundamentally
Daniel> different character.  I'm not convinced that it will or that it won't.

Thanks in particular for your comments on the particular C++ work
items.  I think those combined form a pretty powerful argument.
There's still some unaddressed though:

* Multi-process.  I've seen some hints on the list that this is
  coming, but not enough info to really understand.  This seems like
  something that would affect many areas -- there would seem to be
  challenges from the CLI on down.

* Scalability to lots of shared libraries.  This is tied into the
  above.

Daniel> As Ian said in his talk, ELF is a wonderful format used by almost all
Daniel> of maybe 5% of programs.  If you're going to be ELF-centric, you lose
Daniel> Windows and OS X native debugging - and that's a big user base, even
Daniel> if not directly RH customers.

Yeah, that is true.  But, my understanding is that this is
nevertheless not a goal for Red Hat.  It isn't an anti-goal, either --
just a "don't care", so if it makes things simpler, we can drop
non-ELF.

Daniel> I've seen people hold CDT up as an example of this problem.  I'm not
Daniel> personally involved with Eclipse development, but my understanding
Daniel> from others is that CDT is slow because CDT is slow, not because MI is
Daniel> slow.  DSF is expected to be much faster.

Thanks.

Tom> It would also be worth doing a bit of competitive analysis of the
Tom> leading closed-source debuggers out there.

Daniel> I haven't done this, but my expectation is that more of the
Daniel> differentiation is in the GUI capabilities than the back end
Daniel> capabilities.  If you want to talk about a modern, open-source, widely
Daniel> developer accessible debugger, I think you need to consider GDB +
Daniel> Eclipse as a combination, not GDB alone.  You can argue about what
Daniel> goes after the plus sign.

Dodji sent me some interesting links to totalview docs.  They do seem
to have a lot of additional core functionality -- process-group stuff
similar to what HPD specifies, the ability to evaluate C/Fortran/asm
code fragments (nice!), memory debugging (overflows, bad free calls,
etc), tracepoints.

Tom

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Roadmap beginnings
  2008-07-14 16:34   ` Tom Tromey
@ 2008-07-14 16:45     ` Daniel Jacobowitz
  2008-07-14 16:58       ` Phil Muldoon
  2008-07-14 17:19     ` Ian Lance Taylor
  1 sibling, 1 reply; 19+ messages in thread
From: Daniel Jacobowitz @ 2008-07-14 16:45 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Frysk List

On Mon, Jul 14, 2008 at 10:33:48AM -0600, Tom Tromey wrote:
> Thanks in particular for your comments on the particular C++ work
> items.  I think those combined form a pretty powerful argument.
> There's still some unaddressed though:
> 
> * Multi-process.  I've seen some hints on the list that this is
>   coming, but not enough info to really understand.  This seems like
>   something that would affect many areas -- there would seem to be
>   challenges from the CLI on down.

Yes.  I can say that CodeSourcery is working on this, and I fully
expect to have an implementation posted by ... say ... mid-October.
Focus is likely to be on MI, though it will certainly be somehow
CLI-accessible.  We plan to do the work (or at least the design) in
public; if anyone wants to help...

> * Scalability to lots of shared libraries.  This is tied into the
>   above.

I have some general thoughts about this, but nothing concrete.

> Dodji sent me some interesting links to totalview docs.  They do seem
> to have a lot of additional core functionality -- process-group stuff
> similar to what HPD specifies, the ability to evaluate C/Fortran/asm
> code fragments (nice!), memory debugging (overflows, bad free calls,
> etc), tracepoints.

One thing that might benefit GDB is for someone to sit down and come
up with a few new-approach-to-debugging features like these.  Stick
them up on the wiki or something...

A nice thing about new features is that they're shiny, a.k.a. a good
draw-in for new contributors.

-- 
Daniel Jacobowitz
CodeSourcery

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Roadmap beginnings
  2008-07-14 16:45     ` Daniel Jacobowitz
@ 2008-07-14 16:58       ` Phil Muldoon
  2008-07-14 17:09         ` Daniel Jacobowitz
  0 siblings, 1 reply; 19+ messages in thread
From: Phil Muldoon @ 2008-07-14 16:58 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: Tom Tromey, Frysk List

Daniel Jacobowitz wrote:
> On Mon, Jul 14, 2008 at 10:33:48AM -0600, Tom Tromey wrote:
>   
>> Thanks in particular for your comments on the particular C++ work
>> items.  

Yes thanks, good to have as much input at possible.

>> I think those combined form a pretty powerful argument.
>> There's still some unaddressed though:
>>
>> * Multi-process.  I've seen some hints on the list that this is
>>   coming, but not enough info to really understand.  This seems like
>>   something that would affect many areas -- there would seem to be
>>   challenges from the CLI on down.
>>     
>
> Yes.  I can say that CodeSourcery is working on this, and I fully
> expect to have an implementation posted by ... say ... mid-October.
> Focus is likely to be on MI, though it will certainly be somehow
> CLI-accessible.  We plan to do the work (or at least the design) in
> public; if anyone wants to help...
>   

Being a definite newbie to GDB, how does the community reconcile the 
multiple and large changes that are being discussed, and implement them 
into a stable release base? To an outsider they all seem to be 
converging at once. I know "move to C++" and "multi-process" are 
orthogonal, but they have to exist in the same working code-base. If the 
C++ stuff happens, and it just so happens this new multi-process 
functionality is introduced, what then? Will C "only" patches be 
discouraged? These questions might be better suited to the the GDB list, 
in fact, but I'm curious with all these changes how they will be managed.

> One thing that might benefit GDB is for someone to sit down and come
> up with a few new-approach-to-debugging features like these.  Stick
> them up on the wiki or something...
>
> A nice thing about new features is that they're shiny, a.k.a. a good
> draw-in for new contributors.
>   
When one implements a new feature that has architecture specific 
components, is it the job of the new feature-implementer to implement 
these for as many architectures as possible? Does he champion the cause 
of other folk to go ahead and contribute for their chosen architecture? 
Or is it more of an approach of: "Here is a new feature, this is the 
architecture I implemented it on, lets review if it can work for others?"

Regards

Phil

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Roadmap beginnings
  2008-07-14 16:58       ` Phil Muldoon
@ 2008-07-14 17:09         ` Daniel Jacobowitz
  0 siblings, 0 replies; 19+ messages in thread
From: Daniel Jacobowitz @ 2008-07-14 17:09 UTC (permalink / raw)
  To: Phil Muldoon; +Cc: Tom Tromey, Frysk List

On Mon, Jul 14, 2008 at 05:58:21PM +0100, Phil Muldoon wrote:
> Being a definite newbie to GDB, how does the community reconcile the  
> multiple and large changes that are being discussed, and implement them  
> into a stable release base? To an outsider they all seem to be converging 
> at once. I know "move to C++" and "multi-process" are orthogonal, but they 
> have to exist in the same working code-base. If the C++ stuff happens, and 
> it just so happens this new multi-process functionality is introduced, 
> what then? Will C "only" patches be discouraged? These questions might be 
> better suited to the the GDB list, in fact, but I'm curious with all these 
> changes how they will be managed.

The history of the GDB community is such that it's not used to this
degree of progress :-)  We're feeling our way along.  The community
has experienced a huge surge in development activity over the past ~
year.

As for C++, I'm not yet holding my breath.  But if the transition does
come to pass, the individuals driving it will have to come up with a
plan to not disrupt everyone else's work unduly.  C to C++ has some
advantages in this respect over other language transitions.

> When one implements a new feature that has architecture specific  
> components, is it the job of the new feature-implementer to implement  
> these for as many architectures as possible? Does he champion the cause  
> of other folk to go ahead and contribute for their chosen architecture?  
> Or is it more of an approach of: "Here is a new feature, this is the  
> architecture I implemented it on, lets review if it can work for others?"

Again, it's not like the GDB community has policies on this sort of
thing - it's a very loosely structured group.  My personal position is
that new features should be implemented in ways that do not
unnecessarily restrict support for other platforms, but if platform
specific work is necessary and the feature is shiny enough, platform
maintainers will fill it in of their own accord.

-- 
Daniel Jacobowitz
CodeSourcery

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Roadmap beginnings
  2008-07-14 16:34   ` Tom Tromey
  2008-07-14 16:45     ` Daniel Jacobowitz
@ 2008-07-14 17:19     ` Ian Lance Taylor
  2008-07-14 17:34       ` Daniel Jacobowitz
  2008-07-14 17:35       ` Tom Tromey
  1 sibling, 2 replies; 19+ messages in thread
From: Ian Lance Taylor @ 2008-07-14 17:19 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Daniel Jacobowitz, Frysk List

Tom Tromey <tromey@redhat.com> writes:

> Tom> * Correct expression parsing.  (Though I am told this is extremely
> Tom> difficult to impossible in the general case.)
>
> Daniel> It does a not half bad job, and specific problems with it are fixable.
> Daniel> As for ultimate correctness and completeness, I have serious doubts
> Daniel> that it is feasible - and I also doubt it would see enough use to
> Daniel> justify the enormous investment.  Prove me wrong and we'll merge it :-)
>
> :).  I'm looking around a bit to see if I can find specifics of what
> is wrong.

I don't know if this counts as "expression parsing," but the most
obvious problems that I encounter are the difficulties in working with
STL objects.  Given "std::vector<T> v", I can't do "print v[0]".
Given "std::vector<T>::iterator p", I can't do "print *p".  That is
minimal required functionality for good C++ debugging.  This needs to
work smoothly for STL types and for user defined types.

It would also be nice if gdb could do template parameter defaulting,
although that is rather less important as tab completion can take care
of it.

A related problem, which I don't know how to solve, is that many
simple C++ accessors get inlined, and are not available when
debugging.  This makes it vastly more difficult to debug optimized C++
programs (indeed, this problem is more serious for me in practice than
the debuginfo problems discussed at the summit).

Ian

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Roadmap beginnings
  2008-07-14 17:19     ` Ian Lance Taylor
@ 2008-07-14 17:34       ` Daniel Jacobowitz
  2008-07-14 18:04         ` Tom Tromey
  2008-07-14 18:11         ` Ian Lance Taylor
  2008-07-14 17:35       ` Tom Tromey
  1 sibling, 2 replies; 19+ messages in thread
From: Daniel Jacobowitz @ 2008-07-14 17:34 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: Tom Tromey, Frysk List

On Mon, Jul 14, 2008 at 10:18:53AM -0700, Ian Lance Taylor wrote:
> I don't know if this counts as "expression parsing," but the most
> obvious problems that I encounter are the difficulties in working with
> STL objects.  Given "std::vector<T> v", I can't do "print v[0]".
> Given "std::vector<T>::iterator p", I can't do "print *p".  That is
> minimal required functionality for good C++ debugging.  This needs to
> work smoothly for STL types and for user defined types.

Right.  This is not the expression parsing quagmire - it's definitely
bugs that need to be fixed, but the solutions are (should be) pretty
simple.  Tom and I talked about approaches to use Python support,
shipped with the STL implementation, to provide debugger
implementations of inlined operators that are never emitted out of
line.

> It would also be nice if gdb could do template parameter defaulting,
> although that is rather less important as tab completion can take care
> of it.

Better debug info is definitely required for this.  DWARF defines the
necessary bits, but neither GCC nor GDB implement them.

> A related problem, which I don't know how to solve, is that many
> simple C++ accessors get inlined, and are not available when
> debugging.  This makes it vastly more difficult to debug optimized C++
> programs (indeed, this problem is more serious for me in practice than
> the debuginfo problems discussed at the summit).

Actually, see above.  I assumed that was your problem with the STL
operators.  If there are other problems, please let us know - maybe
after Tom finishes the Bugzilla migration he's got almost done :-)

Thanks for the examples.

-- 
Daniel Jacobowitz
CodeSourcery

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Roadmap beginnings
  2008-07-14 17:19     ` Ian Lance Taylor
  2008-07-14 17:34       ` Daniel Jacobowitz
@ 2008-07-14 17:35       ` Tom Tromey
  2008-07-14 18:13         ` Ian Lance Taylor
  1 sibling, 1 reply; 19+ messages in thread
From: Tom Tromey @ 2008-07-14 17:35 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: Daniel Jacobowitz, Frysk List

>>>>> "Ian" == Ian Lance Taylor <iant@google.com> writes:

Tom> I'm looking around a bit to see if I can find specifics of what
Tom> is wrong.

Ian> I don't know if this counts as "expression parsing," but the most
Ian> obvious problems that I encounter are the difficulties in working with
Ian> STL objects.  Given "std::vector<T> v", I can't do "print v[0]".
Ian> Given "std::vector<T>::iterator p", I can't do "print *p".  That is
Ian> minimal required functionality for good C++ debugging.  This needs to
Ian> work smoothly for STL types and for user defined types.

Thanks.  I remember you mentioning this at the Summit, but I'd
forgotten when sending the email.

Ian> A related problem, which I don't know how to solve, is that many
Ian> simple C++ accessors get inlined, and are not available when
Ian> debugging.  This makes it vastly more difficult to debug optimized C++
Ian> programs (indeed, this problem is more serious for me in practice than
Ian> the debuginfo problems discussed at the summit).

I have seen a few ideas kicked around:

1. Always emit the accessors out-of-line.

2. Emit DWARF code corresponding to the accessors.

3. Write Python code equivalent to the accessors and arrange for the
   debugger to invoke it in the appropriate situations.

#1 seems like the obvious choice, aside from code size problems.  Are
those severe?

Tom

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Roadmap beginnings
  2008-07-14 17:34       ` Daniel Jacobowitz
@ 2008-07-14 18:04         ` Tom Tromey
  2008-07-14 18:12           ` Daniel Jacobowitz
  2008-07-14 18:11         ` Ian Lance Taylor
  1 sibling, 1 reply; 19+ messages in thread
From: Tom Tromey @ 2008-07-14 18:04 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: Ian Lance Taylor, Frysk List

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

Ian> I don't know if this counts as "expression parsing," but the most
Ian> obvious problems that I encounter are the difficulties in working with
Ian> STL objects.  Given "std::vector<T> v", I can't do "print v[0]".
Ian> Given "std::vector<T>::iterator p", I can't do "print *p".  That is
Ian> minimal required functionality for good C++ debugging.  This needs to
Ian> work smoothly for STL types and for user defined types.

Daniel> Right.  This is not the expression parsing quagmire - it's definitely
Daniel> bugs that need to be fixed, but the solutions are (should be) pretty
Daniel> simple.

I thought operator overloading did not work, but a simple test case
shows that it actually does.  And, I can at least print elements of a
std::vector<int> using "p v[3]", and "p *it" works for an iterator of
this vector.

Hmm.  This is much better than I remember.

Tom

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Roadmap beginnings
  2008-07-14 17:34       ` Daniel Jacobowitz
  2008-07-14 18:04         ` Tom Tromey
@ 2008-07-14 18:11         ` Ian Lance Taylor
  1 sibling, 0 replies; 19+ messages in thread
From: Ian Lance Taylor @ 2008-07-14 18:11 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: Tom Tromey, Frysk List

Daniel Jacobowitz <drow@false.org> writes:

>> A related problem, which I don't know how to solve, is that many
>> simple C++ accessors get inlined, and are not available when
>> debugging.  This makes it vastly more difficult to debug optimized C++
>> programs (indeed, this problem is more serious for me in practice than
>> the debuginfo problems discussed at the summit).
>
> Actually, see above.  I assumed that was your problem with the STL
> operators.  If there are other problems, please let us know - maybe
> after Tom finishes the Bugzilla migration he's got almost done :-)

No, I see this problem even when debugging programs which are compiled
without optimization.  This is with the gdb shipped with FC8, based on
6.6.  It may well have improved since then.

Ian

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Roadmap beginnings
  2008-07-14 18:04         ` Tom Tromey
@ 2008-07-14 18:12           ` Daniel Jacobowitz
  0 siblings, 0 replies; 19+ messages in thread
From: Daniel Jacobowitz @ 2008-07-14 18:12 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Ian Lance Taylor, Frysk List

On Mon, Jul 14, 2008 at 12:04:00PM -0600, Tom Tromey wrote:
> I thought operator overloading did not work, but a simple test case
> shows that it actually does.  And, I can at least print elements of a
> std::vector<int> using "p v[3]", and "p *it" works for an iterator of
> this vector.

Yes.  Operator overloading works fine, as long as the available
overloads are relatively easy to locate and distinguish.  If they come
from different scopes or you start needing to make constructor calls
to convert, GDB will rapidly throw up its hands.  That's where we get
into the part of the G++ front end that's been described to me as
"about 10,000 lines to get right".

GDB doesn't know how to call constructors, either - it can't do "new".
That seems like it would be a more serious limitation, but I can't
think the last time I wanted to do it.  Anyway, a simple matter of
programming.

I think the discussion of GDB limitations is wandering a bit afield
for this conversation; I'll stop answering for a bit, and perhaps put
together a combined response or a wiki page with summary, later on.

-- 
Daniel Jacobowitz
CodeSourcery

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Roadmap beginnings
  2008-07-14 17:35       ` Tom Tromey
@ 2008-07-14 18:13         ` Ian Lance Taylor
  0 siblings, 0 replies; 19+ messages in thread
From: Ian Lance Taylor @ 2008-07-14 18:13 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Daniel Jacobowitz, Frysk List

Tom Tromey <tromey@redhat.com> writes:

> Ian> A related problem, which I don't know how to solve, is that many
> Ian> simple C++ accessors get inlined, and are not available when
> Ian> debugging.  This makes it vastly more difficult to debug optimized C++
> Ian> programs (indeed, this problem is more serious for me in practice than
> Ian> the debuginfo problems discussed at the summit).
>
> I have seen a few ideas kicked around:
>
> 1. Always emit the accessors out-of-line.
>
> 2. Emit DWARF code corresponding to the accessors.
>
> 3. Write Python code equivalent to the accessors and arrange for the
>    debugger to invoke it in the appropriate situations.
>
> #1 seems like the obvious choice, aside from code size problems.  Are
> those severe?

Not for me.  I suppose this would be yet another compiler debugging
option.

Python code would be sort of a last resort here, since it presumably
only works for standard classes, not for the classes I define myself.
I do write my own iterators.

Ian

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Debugger Work (Was: Roadmap beginnings)
  2008-07-11 21:53 ` Daniel Jacobowitz
  2008-07-14 16:34   ` Tom Tromey
@ 2008-07-22 20:29   ` Tom Tromey
  1 sibling, 0 replies; 19+ messages in thread
From: Tom Tromey @ 2008-07-22 20:29 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: Frysk List

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

Daniel> Anyway, the trend I wanted to demonstrate: these are
Daniel> straightforward incremental additions to GDB.

Thanks for this note.

Red Hat is going to put its "best C++ debugger" efforts into gdb.

Naturally, this was not an easy decision.  There are two basic reasons
that caused us to revisit gdb.  One reason comes from Daniel's email:
our concrete wish-list is a series of deltas to gdb; of these some are
pretty easy, and some are difficult -- but intrinsically difficult,
not difficult due to some quirk of gdb.  Another reason we took
another look at gdb is the ongoing work by Code Sourcery on non-stop
debugging and multi-process debugging.

Some folks here are worried that gdb will not satisfy Red Hat's needs
in the long term.  Our plan to deal with this contingency is to
re-examine our gdb work to see how we are doing -- either at the 6
month point, or if we hit a major architectural barrier.


Our general plan is similar to what we discussed for frysk, though of
course with some changes:

* We will work on our own branch, with frequent merges from main line.
  We do intend to merge things back to the trunk, but having a branch
  will let us time that effort more easily.  Also we want to have a
  somewhat different patch review approach, so that all team members
  are involved in patch review.  (If you're curious, we'll most likely
  use a git repository for this branch.)

* We'll set up our own mailing list(s) for discussion and patch
  review.  I don't mind reusing the frysk list, but YMMV... please
  discuss.  If you don't want the frysk list, feel free to suggest a
  name for the project.

* We'll continue to discuss our roadmap and milestones in public.
  This will start in earnest once the mailing list situation is clear.

* The C++ issue.  We're still interested in having the debugger be
  implemented in C++.  However, this will probably not be the first
  thing we tackle, primarily because we need various changes that will
  be occurring on gdb CVS trunk.

* FWIW we're going to be looking into a couple other debugging-related
  projects.  In particular, in addition to Alexandre Oliva's work on
  variable tracking in GCC, we will need a sub-project to change g++
  to emit more debug info in some cases.  Also, we'll need to work on
  making gdb work with froggy (maybe on an experimental branch).

Naturally, anybody is welcome to join us in this effort.

Tom

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2008-07-22 20:29 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-07-11 19:53 Roadmap beginnings Tom Tromey
2008-07-11 20:56 ` Jan Kratochvil
2008-07-11 21:37   ` Tom Tromey
2008-07-11 21:54     ` Daniel Jacobowitz
2008-07-11 23:11   ` Kris Van Hees
2008-07-11 21:53 ` Daniel Jacobowitz
2008-07-14 16:34   ` Tom Tromey
2008-07-14 16:45     ` Daniel Jacobowitz
2008-07-14 16:58       ` Phil Muldoon
2008-07-14 17:09         ` Daniel Jacobowitz
2008-07-14 17:19     ` Ian Lance Taylor
2008-07-14 17:34       ` Daniel Jacobowitz
2008-07-14 18:04         ` Tom Tromey
2008-07-14 18:12           ` Daniel Jacobowitz
2008-07-14 18:11         ` Ian Lance Taylor
2008-07-14 17:35       ` Tom Tromey
2008-07-14 18:13         ` Ian Lance Taylor
2008-07-22 20:29   ` Debugger Work (Was: Roadmap beginnings) Tom Tromey
2008-07-11 22:48 ` Roadmap beginnings Phil Muldoon

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).