GDB Focus Group at the 2008 GCC Summit

GDB Focus Group at the 2008 GCC Summit

[Joel Brobecker]

Hello,

we had a couple of 45min sessions where we discussed various items
related to GDB. I took some brief notes, although I might have forgotten
one or two. Anyway, here is what I wrote:

| * Next GDB Release:
| 
|     Lots of new features, but not ready for real release. When
|     the features are in, need a little more maturing time before
|     shipping it in an official release. Suggest next release
|     in 6 months from now (Jan-Feb 2009).
| 
|     For people really interested in trying it out before the official
|     release, perhaps either:
|       - Announce various nightly tarballs that contain the features
|       - Or perhaps create a 6.9 branch but never release 6.9. Just
|         make various pre-releases 6.8.90, 6.8.91, etc.
| 
| * Reverse debugging:
| 
|     4 different implementations, but are starting to converge.
|     We think there is a reasonable chance that this makes 7.0.
| 
| * Calling python function from the CLI:
| 
|     Several possible syntaxes:
|       $(function-name arguments)
|       $function_name (arguments)
| 
|     And also, should be treat the arguments as a simple string,
|     or should we treat each argument as an expression?
| 
|     We reached a consensus and Tom to send it to the gdb list.
| 
| * Python support:
| 
|     Entire work has been split in ~10 patches. Daniel reviewed
|     the patches and 80% of the action items have now been done.
|     Work could be checked in as early as in a month from now.
| 
|     Real issue: Documentation and testsuite.
| 
|     Suggestion: Make sure that the distros build GDB with Python
|     enabled when support is provided in a release.
| 
| * Transition to SVN:
| 
|     Required version (for the client) just released a couple of hours ago:
|     feature allows to checkout a subset of the module (?). There is still
|     no one-line command that allows to check gdb out, so maybe will have
|     a script.
| 
|     Pb: If we want to have a combined tree, we will need to convert
|     binutils, gnulib, etc.
| 
| * Switch to Bugzilla (from gnats):
| 
|     We would like to move to bugzilla, and then need to write somei
|     documentation about the transition, and how to translate old bug
|     numbers into new bug numbers. Use same database as binutils.
| 
| * Using threads inside GDB:
| 
|     Problem: Expression evaluation is synchronous and blocking.
|     While GDB is doing that work, it is not handling other events,
|     which can be a problem in non-stop mode.
|
|     Typical problem is inferior function call that causes two issues:
|       - potential length of time it takes to evaluate
|       - having to re-enter the event loop to wait for function to return.
| 
|     Pedro to think about it and write a proposal. Idea we're gearing
|     towards is one thread that runs the event loop all the time.
| 
| * Fix and continue:
| 
|     Perhaps try to implement this feature through the use of Python.
|     For instance, use python to build a return value, and return that.


-- 
Joel

Re: GDB Focus Group at the 2008 GCC Summit

[Thiago Jung Bauermann]

Zitat von Joel Brobecker <brobecker@adacore.com>:
> Hello,

Hi,

> we had a couple of 45min sessions where we discussed various items
> related to GDB. I took some brief notes, although I might have forgotten
> one or two. Anyway, here is what I wrote:

Thanks.

> | * Next GDB Release:
> |     For people really interested in trying it out before the official
> |     release, perhaps either:
> |       - Announce various nightly tarballs that contain the features
> |       - Or perhaps create a 6.9 branch but never release 6.9. Just
> |         make various pre-releases 6.8.90, 6.8.91, etc.

I was going to say that I prefer the second option, with this reasoning:
when we have the new interesting features in HEAD and in a reasonably
feature-complete state, we could branch and point people at that so that they
can try it out and at the same time be isolated from unrelated unstable
development.

On the other hand, CVS HEAD has pretty much always been reliable to me, so in
the case of GDB that general "release engineering" logic doesn't need to be
used. So I guess the first option is good enough for us, and will save some
branch maintenance work.

> |     Suggestion: Make sure that the distros build GDB with Python
> |     enabled when support is provided in a release.

I think that this is a no-brainer for the distros...

By the way, thanks for organizing the get-together lunch!

And thanks to Daniel for organizing the BoF.
-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center

Re: GDB Focus Group at the 2008 GCC Summit

[Nick Roberts]

 > | * Next GDB Release:
 > | 
 > |     Lots of new features, but not ready for real release. When
 > |     the features are in, need a little more maturing time before
 > |     shipping it in an official release. Suggest next release
 > |     in 6 months from now (Jan-Feb 2009).
 > | 
 > |     For people really interested in trying it out before the official
 > |     release, perhaps either:
 > |       - Announce various nightly tarballs that contain the features
 > |       - Or perhaps create a 6.9 branch but never release 6.9. Just
 > |         make various pre-releases 6.8.90, 6.8.91, etc.

If you are talking about branching now, I think that will mean that most
development will happen on the branch, i.e., there's not much point in
branching.  You might as well make bugfix releases, or what GDB calls respins,
6.8.1, 6.8.2 etc from the 6.8 branch.


 >...
 > | * Fix and continue:
 > | 
 > |     Perhaps try to implement this feature through the use of Python.
 > |     For instance, use python to build a return value, and return that.

Apple GDB already has fix and continue.  Couldn't that be used as a reference
implementaton?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: GDB Focus Group at the 2008 GCC Summit

[Joel Brobecker]

>  > |     For people really interested in trying it out before the official
>  > |     release, perhaps either:
>  > |       - Announce various nightly tarballs that contain the features
>  > |       - Or perhaps create a 6.9 branch but never release 6.9. Just
>  > |         make various pre-releases 6.8.90, 6.8.91, etc.
> 
> If you are talking about branching now, I think that will mean that most
> development will happen on the branch, i.e., there's not much point in
> branching.  You might as well make bugfix releases, or what GDB calls respins,
> 6.8.1, 6.8.2 etc from the 6.8 branch.

The branch would of course be created when the features are checked
in HEAD, not before.

-- 
Joel

Re: GDB Focus Group at the 2008 GCC Summit

[Tom Tromey]

>>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes:

>> | * Fix and continue:
>> | 
>> |     Perhaps try to implement this feature through the use of Python.
>> |     For instance, use python to build a return value, and return that.

Nick> Apple GDB already has fix and continue.  Couldn't that be used
Nick> as a reference implementaton?

I didn't take notes on this, but apparently fix-and-continue is kind
of a pain to implement, and AFAICS needs IDE integration to work
properly anyhow.  The Python idea is more of a cute hack than a really
serious thing.

Tom

Re: GDB Focus Group at the 2008 GCC Summit

[Jim Ingham]

The actual mechanism was not that hard to work from the gdb side, you  
just need the fix bundle and what it is replacing.  The part the IDE  
was most useful for was coordinating building the new fix bundle  
appropriately, and remembering what it was replacing.

 From what I remember, there were two things that were a real pain  
(though Jason can tell in more detail...)

One was the part where you try to validate that the change you are  
about to make is safe (for instance you aren't changing the size of a  
structure, etc...)  You don't need to do this, but it seems really  
unfriendly to let people do stuff that you know is going to cause  
their program to crash, so we felt it was a necessary part of a  
complete implementation.  This is not particularly hard, but it is  
tedious.  There's a bunch of that in our version that might be useful.

The other really painful part is figuring out how to play nice with  
the various runtimes that you're adding methods into.  I don't  
remember all the details, but we had to add hacks to both the C++ and  
the ObjC runtimes to make them like doing surgery on classes on the  
fly.  That's hard because you have to coordinate it with the system  
runtime libraries.  It was also the most fragile part.

We still have some people who use fix and continue but IMHO it was  
never really worth the effort, given how fragile it ended up being.

Jim

On Jun 23, 2008, at 8:17 AM, Tom Tromey wrote:

>>>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes:
>
>>> | * Fix and continue:
>>> |
>>> |     Perhaps try to implement this feature through the use of  
>>> Python.
>>> |     For instance, use python to build a return value, and return  
>>> that.
>
> Nick> Apple GDB already has fix and continue.  Couldn't that be used
> Nick> as a reference implementaton?
>
> I didn't take notes on this, but apparently fix-and-continue is kind
> of a pain to implement, and AFAICS needs IDE integration to work
> properly anyhow.  The Python idea is more of a cute hack than a really
> serious thing.
>
> Tom

Re: GDB Focus Group at the 2008 GCC Summit

[Nick Roberts]

 > Nick> Apple GDB already has fix and continue.  Couldn't that be used
 > Nick> as a reference implementaton?
 > 
 > I didn't take notes on this, but apparently fix-and-continue is kind
 > of a pain to implement, and AFAICS needs IDE integration to work
 > properly anyhow.  The Python idea is more of a cute hack than a really
 > serious thing.

I've never really used it but ISTR that Solaris dbx had this feature and there
all you needed to do when excution was stopped, was edit and compile a file,
myfile.c to myfile.o say, then do "fix myfile.o" followed by "continue" and
execution would continue with the new myfile.o patched into the executable.
This all worked from the command line.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: GDB Focus Group at the 2008 GCC Summit

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> | * Calling python function from the CLI:
Joel> |     Several possible syntaxes:
Joel> |       $(function-name arguments)
Joel> |       $function_name (arguments)
Joel> |     And also, should be treat the arguments as a simple string,
Joel> |     or should we treat each argument as an expression?
Joel> |     We reached a consensus and Tom to send it to the gdb list.

Our consensus was to use the function-like syntax (second example
above) and to parse the arguments as expressions.  This does mean
there is a namespace issue, but we reasoned that we could make all the
standard functions have a "gdb_" prefix or something like that.

I'm about 80% done with implementing this.  I'm using an approach
suggested by Daniel, which is to add a new "convenience function"
type.

Also we agreed that new Python classes should use implicit Python
functions when it makes sense -- that is, use __str__ rather than an
explicit to_string.

Tom

Re: GDB Focus Group at the 2008 GCC Summit

[Tom Tromey]

Tom> Our consensus was to use the function-like syntax (second example
Tom> above) and to parse the arguments as expressions.

I've pushed this to gitorious.  Let me know if you run into problems.
(I also pushed a fix for a pretty serious bug in the "python" command,
so we are not exercising this code as much as I'd like... :)

This change defines a new "internal function" type code.  A
newly-registered internal function is just a value with this type,
which is assigned to a convenience variable of the given name.

This underscores the need for the gdb.Value class to be much more
robust.  Arguments to an implementation of gdb.Function are boxed as
Value objects.  (I considered instead unboxing the 'struct value *'s
into ordinary Python values, but I thought that perhaps it would be
valuable for user functions to be able to access types, even types for
scalars.)

I think at the very least we need a way to unbox a Value.  Perhaps we
should also implement the full range of numeric operators.

Tom

Re: GDB Focus Group at the 2008 GCC Summit

[Thiago Jung Bauermann]

On Mon, 2008-06-23 at 09:15 -0600, Tom Tromey wrote:
> Our consensus was to use the function-like syntax (second example
> above) and to parse the arguments as expressions.  This does mean
> there is a namespace issue, but we reasoned that we could make all the
> standard functions have a "gdb_" prefix or something like that.

What about using a different symbol, such as '%' instead of the '$' used
for convenience variables?
-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center

Re: GDB Focus Group at the 2008 GCC Summit

[Andreas Schwab]

Thiago Jung Bauermann <bauerman@br.ibm.com> writes:

> What about using a different symbol, such as '%' instead of the '$' used
> for convenience variables?

'%' is already taken as the C modulo operator.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GDB Focus Group at the 2008 GCC Summit

[Daniel Jacobowitz]

On Thu, Jul 03, 2008 at 12:26:30AM -0300, Thiago Jung Bauermann wrote:
> On Mon, 2008-06-23 at 09:15 -0600, Tom Tromey wrote:
> > Our consensus was to use the function-like syntax (second example
> > above) and to parse the arguments as expressions.  This does mean
> > there is a namespace issue, but we reasoned that we could make all the
> > standard functions have a "gdb_" prefix or something like that.
> 
> What about using a different symbol, such as '%' instead of the '$' used
> for convenience variables?

I'd like them to be convenience variables (which is what Tom has
implemented).  Putting them in the same namespace is a
well-established tradition and is how Python behaves - plus it lets
them behave transparently like inferior function pointers, which can
also be assigned to convenience variables.

Here's a suggestion: $builtin, like the bash 'builtin' builtin (can't
believe I just wrote that sentence).  That would let us recover any
lost functions.  Well, they aren't really built-in, so maybe some
other name.  The idea of having two names for each, one more
convenient and the other more robust.  WDYT?

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB Focus Group at the 2008 GCC Summit

[Thiago Jung Bauermann]

On Thu, 2008-07-03 at 08:34 -0400, Daniel Jacobowitz wrote:
> On Thu, Jul 03, 2008 at 12:26:30AM -0300, Thiago Jung Bauermann wrote:
> > On Mon, 2008-06-23 at 09:15 -0600, Tom Tromey wrote:
> > > Our consensus was to use the function-like syntax (second example
> > > above) and to parse the arguments as expressions.  This does mean
> > > there is a namespace issue, but we reasoned that we could make all the
> > > standard functions have a "gdb_" prefix or something like that.
> > 
> > What about using a different symbol, such as '%' instead of the '$' used
> > for convenience variables?
> 
> I'd like them to be convenience variables (which is what Tom has
> implemented).  Putting them in the same namespace is a
> well-established tradition and is how Python behaves - plus it lets
> them behave transparently like inferior function pointers, which can
> also be assigned to convenience variables.

Ok.

> Here's a suggestion: $builtin, like the bash 'builtin' builtin (can't
> believe I just wrote that sentence).  That would let us recover any
> lost functions.  Well, they aren't really built-in, so maybe some
> other name.  The idea of having two names for each, one more
> convenient and the other more robust.  WDYT?

Sounds good to me. If we provide a robust way to get to the Python
function, then IMHO it's not necessary to use a gdb_ prefix and we can
use bare function names. This would make the use of those functions more
natural.
-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center

Re: GDB Focus Group at the 2008 GCC Summit

[Tom Tromey]

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

Daniel> Here's a suggestion: $builtin, like the bash 'builtin' builtin (can't
Daniel> believe I just wrote that sentence).  That would let us recover any
Daniel> lost functions.  Well, they aren't really built-in, so maybe some
Daniel> other name.  The idea of having two names for each, one more
Daniel> convenient and the other more robust.  WDYT?

This is fine except for 'set $builtin = 0'.  I am not really concerned
about it though.

Actually it would be fine by me to install things as both
$gdb_whatever and $whatever by default, not worry if users overwrite
$whatever, and try to have scripts always use the namespaced form.

The current code installs the documentation under "help function name".
But if the user does "set $other = $name; help function other", he
won't get anything sensible.  Perhaps 'help' needs a special case; but
then command completion needs a special case too.

Tom

Re: GDB Focus Group at the 2008 GCC Summit

[Daniel Jacobowitz]

On Thu, Jul 03, 2008 at 08:32:54PM -0600, Tom Tromey wrote:
> The current code installs the documentation under "help function name".
> But if the user does "set $other = $name; help function other", he
> won't get anything sensible.

IMO, that's fine.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB Focus Group at the 2008 GCC Summit

[Jason Molenda]

On Jun 19, 2008, at 12:09 PM, Joel Brobecker wrote:

> |
> | * Fix and continue:
> |
> |     Perhaps try to implement this feature through the use of Python.
> |     For instance, use python to build a return value, and return  
> that.

As Jim mentioned, we did this to gdb here at Apple four or five years  
back.  I started my work on F&C by reading through HP's gdb changes  
(in "wdb", their version of gdb).  Their implementation is very gdb- 
centric and may be a better place to start looking - if I remember  
correctly gdb rebuilds the .o file itself as a part of the "fix"  
command, for instance.

With our F&C system, we start by compiling a PIC library from the .o  
file (a "bundle" on Mac OS X).  We've modified gcc to pad the  
prologues of functions with a few nop instructions and we've also  
changed the compiler to use indirect references to static objects  
within the compilation unit.  Normally a function accessing a file- 
static variable, would use a pic-based reference once it had been  
finished with the linker.  But we want to map these all to the  
original static/globals that we started with so we need the  
indirection.  (you don't want a global to have a value of 10, fix in a  
file and then one compilation unit thinks it has a value of 0 while  
the rest of the program is still pointing to the one with a 10.)

Before we load the newly built code, we try to look over the types in  
the .o file and ensure that arguments haven't been added to functions,  
structure sizes haven't been changed, etc.  Again, half of the program  
thinking that a function takes 2 arguments and another part thinking  
it takes 3 will work poorly.

Once the new .o file has been loaded into memory, we rewrite the nop's  
in the prologues of all earlier versions of the functions to point to  
the newest versions.  So if someone has a pointer to one of the  
original functions, they'll still end up calling the new one.  We  
update the indirection table for file statics so any references to  
globals/statics in the just-loaded .o file will go to the original  
versions, if they exist.

The IDE is responsible for removing & reinserting breakpoints at the  
correct line numbers.  If you had a breakpoint on main.c:35 and you  
added a couple of lines of code earlier in the file, that breakpoint  
needs to be moved to main.c:37.

If you're stopped in a function that was just updated, the IDE tells  
gdb to re-set to the corresponding line number in the newly loaded  
file.  This obviously has no chance of working except at -O0.  And  
with i386/ppc code, most functions that reference static/global data  
load $pc into a register so they can load objects pc-relative.  You  
need to find that setup in the new function, compute what that picbase  
register should hold and set it ahead of time.

gdb then marks the psymtab/symtab of the just-replaced file as  
'obsolete' so when we are doing a symbol-to-addr lookup we don't find  
them.  At the same time, if you're doing an addr-to-symbol lookup you  
want to find the old, obsoleted files -- you might have a function on  
the stack still or something like that.

As you can tell from the above, at Apple I offload some of the work to  
the compiler and some to the IDE.  You get the impression that the wdb  
folks did it all by themselves - they have all sorts of chicanery to  
squeeze the jump instruction into functions regardless of how long  
they are, or if you're stopped in the middle of the code it wants to  
rewrite.

All that being said, it's a pretty fragile mechanism.  C/C++ weren't  
designed for this kind of thing.  It works fine on trivial examples  
and makes great demoware but it's very easy to crash your program when  
you're trying to use this on real programs/real problems.  I've heard  
some success stories from people who are doing specific narrow things,  
or where re-starting their debug session and getting back to the  
problem spot are so expensive that they're willing to take a risk.   
But IMO, in practice, it's less useful than any of us would have liked.

wdb and Apple's gdb implementations are GPL'ed of course so for more  
details it's probably best to just browse the sources.

J

Re: GDB Focus Group at the 2008 GCC Summit

[Nick Roberts]

 > The IDE is responsible for removing & reinserting breakpoints at the  
 > correct line numbers.  If you had a breakpoint on main.c:35 and you  
 > added a couple of lines of code earlier in the file, that breakpoint  
 > needs to be moved to main.c:37.

Quite apart from fix and continue, it would be useful when GDB realises that
an executable has been recompiled and says:

  `myprog' has changed; re-reading symbols.

if it could also compute and print the new breakpoint locations, possibly
only in MI as an event notification ("=breakpoints-changed").

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: GDB Focus Group at the 2008 GCC Summit

[Nick Roberts]

Nick Roberts writes:
 >  > The IDE is responsible for removing & reinserting breakpoints at the  
 >  > correct line numbers.  If you had a breakpoint on main.c:35 and you  
 >  > added a couple of lines of code earlier in the file, that breakpoint  
 >  > needs to be moved to main.c:37.
 > 
 > Quite apart from fix and continue, it would be useful when GDB realises that
 > an executable has been recompiled and says:
 > 
 >   `myprog' has changed; re-reading symbols.
 > 
 > if it could also compute and print the new breakpoint locations, possibly
 > only in MI as an event notification ("=breakpoints-changed").

I was thinking that GDB could detect that the location had changed but maybe
(as Jason suggests the IDE should do it (certainly if the edit source in Emacs
the breakpoint icon moves with it's associated line).  In which case it would
seem useful to have an MI command that could move an existing breakpoint, e.g.,

   -break-insert -m BPTNO FILE:LINE

rather than delete the existing breakpoint and create a new one so that the
breakpoint number is preserved.  If the example above is breakpoint 4:

   -break-insert -m 4 main.c:37

Perhaps Apple GDB already does something like this.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

[MI] changing breakpoint location (Was: GDB Focus Group at the 2008 GCC Summit)

[Vladimir Prus]

Nick Roberts wrote:

> Nick Roberts writes:
>  >  > The IDE is responsible for removing & reinserting breakpoints at the
>  >  > correct line numbers.  If you had a breakpoint on main.c:35 and you
>  >  > added a couple of lines of code earlier in the file, that breakpoint
>  >  > needs to be moved to main.c:37.
>  > 
>  > Quite apart from fix and continue, it would be useful when GDB realises that
>  > an executable has been recompiled and says:
>  > 
>  >   `myprog' has changed; re-reading symbols.
>  > 
>  > if it could also compute and print the new breakpoint locations, possibly
>  > only in MI as an event notification ("=breakpoints-changed").
> 
> I was thinking that GDB could detect that the location had changed but maybe
> (as Jason suggests the IDE should do it (certainly if the edit source in Emacs
> the breakpoint icon moves with it's associated line).  In which case it would
> seem useful to have an MI command that could move an existing breakpoint, e.g.,
> 
>    -break-insert -m BPTNO FILE:LINE
> 
> rather than delete the existing breakpoint and create a new one so that the
> breakpoint number is preserved.  If the example above is breakpoint 4:
> 
>    -break-insert -m 4 main.c:37

The frontend logic to remove and reinsert breakpoint when a location changes is
certainly messy, so I guess such a command would be nice to have. Beware that it
would require some core gdb changes -- breakpoint.c does not support
moving breakpoint location, either.

- Volodya

Re: GDB Focus Group at the 2008 GCC Summit

[Mark Kettenis]

> Date: Thu, 19 Jun 2008 15:09:42 -0400
> From: Joel Brobecker <brobecker@adacore.com>
> 
> Hello,
> 
> we had a couple of 45min sessions where we discussed various items
> related to GDB. I took some brief notes, although I might have forgotten
> one or two. Anyway, here is what I wrote:
> 
> | * Transition to SVN:
> | 
> |     Required version (for the client) just released a couple of hours ago:
> |     feature allows to checkout a subset of the module (?). There is still
> |     no one-line command that allows to check gdb out, so maybe will have
> |     a script.
> | 
> |     Pb: If we want to have a combined tree, we will need to convert
> |     binutils, gnulib, etc.

Objection!  I have played with SVN for work and I really dilike the
fact that a checked out repository is very grep unfriendly.

> | * Using threads inside GDB:
> | 
> |     Problem: Expression evaluation is synchronous and blocking.
> |     While GDB is doing that work, it is not handling other events,
> |     which can be a problem in non-stop mode.
> |
> |     Typical problem is inferior function call that causes two issues:
> |       - potential length of time it takes to evaluate
> |       - having to re-enter the event loop to wait for function to return.
> | 
> |     Pedro to think about it and write a proposal. Idea we're gearing
> |     towards is one thread that runs the event loop all the time.

I guess something like this is inevitable, but I'm not happy with
using threads.  Threads and signals don't mix really well, and
ptrace(2) depends heavily on threads.

Re: GDB Focus Group at the 2008 GCC Summit

[Joel Brobecker]

> Objection!  I have played with SVN for work and I really dilike the
> fact that a checked out repository is very grep unfriendly.

Could you tell us what part is causing trouble with grep?
Is it the fact that there is a copy of the checked out version
inside the sandbox metadata?

Roughly around the same time that the GCC project transitioned to SVN,
we at AdaCore also slowly started transitioning our own repositories
away from CVS to SVN as well. There might be some issues that SVN
introduce (huge amount of metadata, for instance), but overall we have
found that the benefits it brings over CVS are well worth the transition.

The alternatives are: (1) staying with CVS or (2) transitioning to
another VC system. I do think that we have much to gain by transitioning
to a more modern VC. SVN seemed the natural choice since the GCC
project adopted it, and the transition from CVS to SVN is very easy
from the user's perspective.  I don't mind looking at other alternatives,
but I think it would only make sense if we looked at distributed VC systems
such as git or hg.

-- 
Joel

Re: GDB Focus Group at the 2008 GCC Summit

[Andrew STUBBS]

Mark Kettenis wrote:
> Objection!  I have played with SVN for work and I really dilike the
> fact that a checked out repository is very grep unfriendly.

grep --exclude=*.svn-base

I have it in an alias.

Re: GDB Focus Group at the 2008 GCC Summit

[Andreas Schwab]

Andrew STUBBS <andrew.stubbs@st.com> writes:

> Mark Kettenis wrote:
>> Objection!  I have played with SVN for work and I really dilike the
>> fact that a checked out repository is very grep unfriendly.
>
> grep --exclude=*.svn-base

Or use M-x rgrep in Emacs.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GDB Focus Group at the 2008 GCC Summit

[Michael Snyder]

On Tue, 2008-06-24 at 09:35 +0100, Andrew STUBBS wrote:
> Mark Kettenis wrote:
> > Objection!  I have played with SVN for work and I really dilike the
> > fact that a checked out repository is very grep unfriendly.
> 
> grep --exclude=*.svn-base
> 
> I have it in an alias.

Yes, I have to do something similar when I diff two cvs trees:

diff -rup -x CVS ...

Re: GDB Focus Group at the 2008 GCC Summit

[Daniel Jacobowitz]

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

On Tue, Jun 24, 2008 at 09:35:46AM +0100, Andrew STUBBS wrote:
> Mark Kettenis wrote:
>> Objection!  I have played with SVN for work and I really dilike the
>> fact that a checked out repository is very grep unfriendly.
>
> grep --exclude=*.svn-base
>
> I have it in an alias.

A slightly more thorough version attached, for anyone who wants it.

Another alternative is to use svk; one of the advantages is smaller
working trees.

-- 
Daniel Jacobowitz
CodeSourcery

[-- Attachment #2: svngrep --]
[-- Type: text/plain, Size: 1694 bytes --]

#!/bin/bash

# svngrep - recursive grep safe for SVN trees (and quilt)
# Copyright (C) 2008 Daniel Jacobowitz <dan@codesourcery.com>

# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.

# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.

# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.

args=()
files=()
next_opt=false
next_file=false
need_pattern=true
for arg; do
    if $next_file; then
	if $need_pattern; then
	    args=("${args[@]}" "$arg")
	    need_pattern=false
	else
	    files=("${files[@]}" "$arg")
	fi
    elif $next_opt; then
	next_opt=false
	args=("${args[@]}" "$arg")
    else
	case "$arg" in
	    -e|-f)
		need_pattern=false
		next_opt=true
		args=("${args[@]}" "$arg")
		;;
	    -m|-A|-B|-C|-D|-d)
		next_opt=true
		args=("${args[@]}" "$arg")
		;;
	    -r)
		# Just consume -r.
		;;
	    --)
		args=("${args[@]}" "$arg")
		next_file=true
		;;
	    -*)
		args=("${args[@]}" "$arg")
		;;
	    *)
		if $need_pattern; then
		    args=("${args[@]}" "$arg")
		    need_pattern=false
		else
		    files=("${files[@]}" "$arg")
		fi
		next_file=true
		;;
	esac
    fi
done

find "${files[@]}" -name .svn -prune \
  -o -name .pc -prune -o -name \*~ -prune \
  -o -type f -print0 | xargs -0 grep "${args[@]}"

RE: GDB Focus Group at the 2008 GCC Summit

[Dave Korn]

Andrew STUBBS wrote on 24 June 2008 09:36:

> Mark Kettenis wrote:
>> Objection!  I have played with SVN for work and I really dilike the
>> fact that a checked out repository is very grep unfriendly.
> 
> grep --exclude=*.svn-base
> 
> I have it in an alias.

  I have it set in my GREP_OPTIONS in my .bashrc.

  And I can even imagine situations where I might be glad of the ability to
grep both the original unmodified version of a file and the locally-modified
version in one simple operation :)

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....