* RFC: fix PR 12707
@ 2013-01-14 19:31 Tom Tromey
2013-01-15 15:12 ` Pedro Alves
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Tom Tromey @ 2013-01-14 19:31 UTC (permalink / raw)
To: gdb-patches
This patch fixes PR 12707.
It probably needs various preceding patches, though I didn't really
check in detail.
The bug here is that "set print demangle off" hasn't worked properly
since the physname patches went in.
The basic problem is something Doug pointed out a while ago: the DWARF
reader puts the demangled name into the general_symbol_info, and the
demangled name in the cplus_specific structure is empty.
While looking into this I also noticed that the physname code is
generally avoiding the demangled name hash. This is not ideal, because
it means that names that don't require the physname treatment (that is,
ones with a linkage name) are using more memory than is strictly
necessary.
The situation here is still not totally ideal:
* There are still some physname bugs, see bugzilla
* gdb calls cplus_demangle in many places with different options.
This seems like it ought to cause bugs. (See below for an instance.)
* The name-setting code in new_symbol_full is now a mess; though
I argue with 3 or 4 "get a DWARF name" functions we were already well
down this road.
Regression testing this showed two things. First, the py-symbol.exp
test is clearly wrong.
Second, I had to change cmpd-minsyms.exp to account for the symtab.c
change, which in turn was required to align symbol_find_demangled_name
with what dwarf2read.c is doing.
This is the one bit I am unsure about.
Built and regtested on x86-64.
New test case included.
Tom
PR symtab/12707:
* dwarf2read.c (new_symbol_full): Preserve the mangled name.
* symtab.c (symbol_find_demangled_name): Pass DMGL_RET_DROP
to cplus_demangle.
* gdb.cp/cmpd-minsyms.exp: Don't expect return type.
* gdb.cp/print-demangle.exp: New file.
* gdb.python/py-symbol.exp: Fix expected linkage name.
---
gdb/dwarf2read.c | 52 ++++++++++++++++++++++++------
gdb/symtab.c | 2 +-
gdb/testsuite/gdb.cp/cmpd-minsyms.exp | 6 +--
gdb/testsuite/gdb.cp/print-demangle.exp | 32 +++++++++++++++++++
gdb/testsuite/gdb.python/py-symbol.exp | 2 +-
5 files changed, 77 insertions(+), 17 deletions(-)
create mode 100644 gdb/testsuite/gdb.cp/print-demangle.exp
diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index 4357746..76e3a79 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -15746,7 +15746,6 @@ new_symbol_full (struct die_info *die, struct type *type, struct dwarf2_cu *cu,
name = dwarf2_name (die, cu);
if (name)
{
- const char *linkagename;
int suppress_add = 0;
if (space)
@@ -15757,16 +15756,47 @@ new_symbol_full (struct die_info *die, struct type *type, struct dwarf2_cu *cu,
/* Cache this symbol's name and the name's demangled form (if any). */
SYMBOL_SET_LANGUAGE (sym, cu->language);
- linkagename = dwarf2_physname (name, die, cu);
- SYMBOL_SET_NAMES (sym, linkagename, strlen (linkagename), 0, objfile);
-
- /* Fortran does not have mangling standard and the mangling does differ
- between gfortran, iFort etc. */
- if (cu->language == language_fortran
- && symbol_get_demangled_name (&(sym->ginfo)) == NULL)
- symbol_set_demangled_name (&(sym->ginfo),
- dwarf2_full_name (name, die, cu),
- NULL);
+
+ attr = dwarf2_attr (die, DW_AT_linkage_name, cu);
+ if (attr == NULL)
+ attr = dwarf2_attr (die, DW_AT_MIPS_linkage_name, cu);
+
+ if (cu->language != language_fortran
+ && (attr != NULL && DW_STRING (attr) != NULL)
+ /* If this DIE does not need a namespace, but we have a
+ mangled form, then we may be seeing a static variable in
+ a method -- but we don't want to use the ordinary
+ demangler in this case. */
+ && die_needs_namespace (die, cu))
+ {
+ /* Let the symtab code do the demangling. The main benefit
+ of this approach is better caching. */
+ SYMBOL_SET_NAMES (sym, DW_STRING (attr), strlen (DW_STRING (attr)),
+ 0, objfile);
+ }
+ else
+ {
+ const char *physname;
+
+ physname = dwarf2_physname (name, die, cu);
+ /* If we have a mangled form, make sure to preserve it. */
+ if (cu->language != language_fortran
+ && attr != NULL && DW_STRING (attr) != NULL)
+ {
+ SYMBOL_LINKAGE_NAME (sym) = DW_STRING (attr);
+ symbol_set_demangled_name (&(sym->ginfo), physname, objfile);
+ }
+ else
+ SYMBOL_SET_NAMES (sym, physname, strlen (physname), 0, objfile);
+
+ /* Fortran does not have mangling standard and the mangling
+ does differ between gfortran, iFort etc. */
+ if (cu->language == language_fortran
+ && symbol_get_demangled_name (&(sym->ginfo)) == NULL)
+ symbol_set_demangled_name (&(sym->ginfo),
+ dwarf2_full_name (name, die, cu),
+ objfile);
+ }
/* Default assumptions.
Use the passed type or decode it from the die. */
diff --git a/gdb/symtab.c b/gdb/symtab.c
index 59ef4c1..5e0f5d4 100644
--- a/gdb/symtab.c
+++ b/gdb/symtab.c
@@ -586,7 +586,7 @@ symbol_find_demangled_name (struct general_symbol_info *gsymbol,
|| gsymbol->language == language_auto)
{
demangled =
- cplus_demangle (mangled, DMGL_PARAMS | DMGL_ANSI);
+ cplus_demangle (mangled, DMGL_PARAMS | DMGL_ANSI | DMGL_RET_DROP);
if (demangled != NULL)
{
gsymbol->language = language_cplus;
diff --git a/gdb/testsuite/gdb.cp/cmpd-minsyms.exp b/gdb/testsuite/gdb.cp/cmpd-minsyms.exp
index 49ee0ed..e6dc4d2 100644
--- a/gdb/testsuite/gdb.cp/cmpd-minsyms.exp
+++ b/gdb/testsuite/gdb.cp/cmpd-minsyms.exp
@@ -43,15 +43,13 @@ foreach sym $min_syms {
gdb_test_no_output "set language c++"
# A list of minimal symbol names to check.
-# Note that GDB<char>::even_harder<int>(char) is quoted and includes
-# the return type. This is necessary because this is the demangled name
-# of the minimal symbol.
+# Note that GDB<char>::even_harder<int>(char) is quoted.
set min_syms [list \
"GDB<int>::operator ==" \
"GDB<int>::operator==(GDB<int> const&)" \
"GDB<char>::harder(char)" \
"GDB<int>::harder(int)" \
- {"int GDB<char>::even_harder<int>(char)"} \
+ {"GDB<char>::even_harder<int>(char)"} \
"GDB<int>::simple()"]
foreach sym $min_syms {
diff --git a/gdb/testsuite/gdb.cp/print-demangle.exp b/gdb/testsuite/gdb.cp/print-demangle.exp
new file mode 100644
index 0000000..b60e029
--- /dev/null
+++ b/gdb/testsuite/gdb.cp/print-demangle.exp
@@ -0,0 +1,32 @@
+# Copyright (C) 2013 Free Software Foundation, Inc.
+
+# 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/>.
+
+if { [skip_cplus_tests] } { continue }
+
+standard_testfile bool.cc
+
+if {[prepare_for_testing $testfile.exp $testfile $srcfile {debug c++}]} {
+ return -1
+}
+
+runto_main
+
+gdb_breakpoint "return_true"
+
+gdb_continue_to_breakpoint "return_true"
+
+gdb_test_no_output "set print demangle off"
+
+gdb_test "frame" " _Z11return_truev .*"
diff --git a/gdb/testsuite/gdb.python/py-symbol.exp b/gdb/testsuite/gdb.python/py-symbol.exp
index f67af54..a9fdff7 100644
--- a/gdb/testsuite/gdb.python/py-symbol.exp
+++ b/gdb/testsuite/gdb.python/py-symbol.exp
@@ -142,7 +142,7 @@ gdb_test "python print (cplusfunc.is_argument)" "False" "Test func.is_argument"
gdb_test "python print (cplusfunc.is_function)" "True" "Test func.is_function"
gdb_test "python print (cplusfunc.name)" "SimpleClass::valueofi().*" "Test func.name"
gdb_test "python print (cplusfunc.print_name)" "SimpleClass::valueofi().*" "Test func.print_name"
-gdb_test "python print (cplusfunc.linkage_name)" "SimpleClass::valueofi().*" "Test func.linkage_name"
+gdb_test "python print (cplusfunc.linkage_name)" _ZN11SimpleClass8valueofiEv "Test func.linkage_name"
gdb_test "python print (cplusfunc.addr_class == gdb.SYMBOL_LOC_BLOCK)" "True" "Test func.addr_class"
# Test is_valid when the objfile is unloaded. This must be the last
--
1.7.7.6
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: RFC: fix PR 12707
2013-01-14 19:31 RFC: fix PR 12707 Tom Tromey
@ 2013-01-15 15:12 ` Pedro Alves
2013-01-15 15:32 ` Tom Tromey
2013-01-15 16:59 ` Jan Kratochvil
2013-01-15 17:22 ` Jan Kratochvil
2 siblings, 1 reply; 15+ messages in thread
From: Pedro Alves @ 2013-01-15 15:12 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb-patches
No comments on the patch itself.
On 01/14/2013 07:31 PM, Tom Tromey wrote:
> # A list of minimal symbol names to check.
> -# Note that GDB<char>::even_harder<int>(char) is quoted and includes
> -# the return type. This is necessary because this is the demangled name
> -# of the minimal symbol.
> +# Note that GDB<char>::even_harder<int>(char) is quoted.
This caught my eye though. Is there still a reason for the quoting?
(I don't think I understood the original comment's reasoning
fully either.)
> set min_syms [list \
> "GDB<int>::operator ==" \
> "GDB<int>::operator==(GDB<int> const&)" \
> "GDB<char>::harder(char)" \
> "GDB<int>::harder(int)" \
> - {"int GDB<char>::even_harder<int>(char)"} \
> + {"GDB<char>::even_harder<int>(char)"} \
> "GDB<int>::simple()"]
--
Pedro Alves
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: RFC: fix PR 12707
2013-01-14 19:31 RFC: fix PR 12707 Tom Tromey
2013-01-15 15:12 ` Pedro Alves
@ 2013-01-15 16:59 ` Jan Kratochvil
2013-01-15 17:05 ` Tom Tromey
2013-01-15 17:22 ` Jan Kratochvil
2 siblings, 1 reply; 15+ messages in thread
From: Jan Kratochvil @ 2013-01-15 16:59 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb-patches
On Mon, 14 Jan 2013 20:31:09 +0100, Tom Tromey wrote:
> It probably needs various preceding patches, though I didn't really
> check in detail.
Yes, I wanted to test it but I do not see how to patch it, could you push it
to an archer branch?
Thanks,
Jan
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RFC: fix PR 12707
2013-01-14 19:31 RFC: fix PR 12707 Tom Tromey
2013-01-15 15:12 ` Pedro Alves
2013-01-15 16:59 ` Jan Kratochvil
@ 2013-01-15 17:22 ` Jan Kratochvil
2013-01-17 21:25 ` Tom Tromey
2 siblings, 1 reply; 15+ messages in thread
From: Jan Kratochvil @ 2013-01-15 17:22 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb-patches
On Mon, 14 Jan 2013 20:31:09 +0100, Tom Tromey wrote:
> Second, I had to change cmpd-minsyms.exp to account for the symtab.c
> change, which in turn was required to align symbol_find_demangled_name
> with what dwarf2read.c is doing.
Yes, this is a problem I faced when thinking about fixing this issue:
$ nm -C gdb.cp/cmpd-minsyms
000000000040067d W int GDB<char>::even_harder<int>(char)
FSF GDB:
(gdb) b int GDB<char>::even_harder<int>(char)
Breakpoint 1 at 0x400681
patched GDB:
(gdb) b int GDB<char>::even_harder<int>(char)
Function "int GDB<char>::even_harder<int>(char)" not defined.
Make breakpoint pending on future shared library load? (y or [n])
(The ticks ' do not help it.)
I find "int GDB<char>::even_harder<int>(char)" to be a valid (or at least also
valid) demangled name for that function so I believe GDB should know that
name.
Thanks,
Jan
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RFC: fix PR 12707
2013-01-15 17:22 ` Jan Kratochvil
@ 2013-01-17 21:25 ` Tom Tromey
2013-01-17 21:54 ` Jan Kratochvil
0 siblings, 1 reply; 15+ messages in thread
From: Tom Tromey @ 2013-01-17 21:25 UTC (permalink / raw)
To: Jan Kratochvil; +Cc: gdb-patches
>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
Tom> Second, I had to change cmpd-minsyms.exp to account for the symtab.c
Tom> change, which in turn was required to align symbol_find_demangled_name
Tom> with what dwarf2read.c is doing.
Jan> Yes, this is a problem I faced when thinking about fixing this issue:
Jan> (gdb) b int GDB<char>::even_harder<int>(char)
Jan> Function "int GDB<char>::even_harder<int>(char)" not defined.
Jan> Make breakpoint pending on future shared library load? (y or [n])
Jan> I find "int GDB<char>::even_harder<int>(char)" to be a valid (or at
Jan> least also valid) demangled name for that function so I believe GDB
Jan> should know that name.
I agree in principle, but I think the current approach to doing this is
at least odd, and probably unintentional and incorrect.
Right now, minsyms have the return type in their demangled name, but
other symbols do not.
This means that the above could possibly work on an out-of-line
instance, but never on an inline instance. In a large program this
would mean missing some breakpoint locations.
Changing other symbols to include the return type also seems difficult.
The proposed change means that a breakpoint could still be set, just not
including the return type.
Tom
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RFC: fix PR 12707
2013-01-17 21:25 ` Tom Tromey
@ 2013-01-17 21:54 ` Jan Kratochvil
2013-01-17 21:59 ` Tom Tromey
0 siblings, 1 reply; 15+ messages in thread
From: Jan Kratochvil @ 2013-01-17 21:54 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb-patches
On Thu, 17 Jan 2013 22:25:35 +0100, Tom Tromey wrote:
> I agree in principle, but I think the current approach to doing this is
> at least odd, and probably unintentional and incorrect.
I agree but in practice it works.
> Changing other symbols to include the return type also seems difficult.
I do not see why. There exists no demangled name with the return type
anywhere for normal non-template functions.
> The proposed change means that a breakpoint could still be set, just not
> including the return type.
It cannot be set by copy-pasting the symbol name from nm or similar tools.
The data structures could contain both names - with the return type and
without the return type - so that GDB does match both.
Thanks,
Jan
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RFC: fix PR 12707
2013-01-17 21:54 ` Jan Kratochvil
@ 2013-01-17 21:59 ` Tom Tromey
2013-01-17 22:04 ` Jan Kratochvil
0 siblings, 1 reply; 15+ messages in thread
From: Tom Tromey @ 2013-01-17 21:59 UTC (permalink / raw)
To: Jan Kratochvil; +Cc: gdb-patches
Tom> Changing other symbols to include the return type also seems difficult.
Jan> I do not see why. There exists no demangled name with the return type
Jan> anywhere for normal non-template functions.
I expect it will break expression parsing.
Tom> The proposed change means that a breakpoint could still be set, just not
Tom> including the return type.
Jan> It cannot be set by copy-pasting the symbol name from nm or similar tools.
Of all the choices I consider this the least bad.
Jan> The data structures could contain both names - with the return type and
Jan> without the return type - so that GDB does match both.
I think that would require too much memory for what is really a marginal
feature.
Tom
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RFC: fix PR 12707
2013-01-17 21:59 ` Tom Tromey
@ 2013-01-17 22:04 ` Jan Kratochvil
2013-01-17 22:33 ` Jan Kratochvil
2013-01-18 14:31 ` Tom Tromey
0 siblings, 2 replies; 15+ messages in thread
From: Jan Kratochvil @ 2013-01-17 22:04 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb-patches
On Thu, 17 Jan 2013 22:59:49 +0100, Tom Tromey wrote:
> Tom> Changing other symbols to include the return type also seems difficult.
>
> Jan> I do not see why. There exists no demangled name with the return type
> Jan> anywhere for normal non-template functions.
>
> I expect it will break expression parsing.
Then it should be fixed but IIRC it works with the linespec parser even
without quotes.
> I think that would require too much memory for what is really a marginal
> feature.
I find it an essential feature to be able to break on function where the
application has crashed, I was using it myself several times for some C++
application (Firefox probably).
Thanks,
Jan
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RFC: fix PR 12707
2013-01-17 22:04 ` Jan Kratochvil
@ 2013-01-17 22:33 ` Jan Kratochvil
2013-01-18 14:31 ` Tom Tromey
1 sibling, 0 replies; 15+ messages in thread
From: Jan Kratochvil @ 2013-01-17 22:33 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb-patches
On Thu, 17 Jan 2013 23:04:37 +0100, Jan Kratochvil wrote:
> On Thu, 17 Jan 2013 22:59:49 +0100, Tom Tromey wrote:
> > I think that would require too much memory for what is really a marginal
> > feature.
>
> I find it an essential feature to be able to break on function where the
> application has crashed, I was using it myself several times for some C++
> application (Firefox probably).
For example in this simple case:
_Z6outer2IsEPFilES1_
displayed with nm -C as:
int (*outer2<short>(int (*)(long)))(long)
But one has to transform it for GDB into the DMGL_RET_DROP form as:
outer2<short>(int (*)(long))
Which seems non-trivial for a copy-paste to me, sure it can be much more
complicated.
Regards,
Jan
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RFC: fix PR 12707
2013-01-17 22:04 ` Jan Kratochvil
2013-01-17 22:33 ` Jan Kratochvil
@ 2013-01-18 14:31 ` Tom Tromey
2013-01-18 14:35 ` Jan Kratochvil
1 sibling, 1 reply; 15+ messages in thread
From: Tom Tromey @ 2013-01-18 14:31 UTC (permalink / raw)
To: Jan Kratochvil; +Cc: gdb-patches
Tom> I expect it will break expression parsing.
Jan> Then it should be fixed but IIRC it works with the linespec parser even
Jan> without quotes.
I don't think we're talking about the same thing.
I was contemplating the change you implied -- adding return types to all
symbols. I think this change would make symbol lookup during expression
parsing fail. In this case one does not include the return type in the
lookup name.
It works ok now precisely because the debug symbols don't include this
information. Here it is without debuginfo:
(gdb) p GDB<char>::even_harder<int> ('a')
No symbol "GDB<char>" in current context.
(gdb) p 'int GDB<char>::even_harder<int>' ('a')
$1 = 97
Tom> I think that would require too much memory for what is really a marginal
Tom> feature.
Jan> I find it an essential feature to be able to break on function where the
Jan> application has crashed, I was using it myself several times for some C++
Jan> application (Firefox probably).
Ok. I'm going to drop this patch.
Tom
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: RFC: fix PR 12707
2013-01-18 14:31 ` Tom Tromey
@ 2013-01-18 14:35 ` Jan Kratochvil
2013-01-18 15:04 ` Tom Tromey
0 siblings, 1 reply; 15+ messages in thread
From: Jan Kratochvil @ 2013-01-18 14:35 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb-patches
On Fri, 18 Jan 2013 15:30:43 +0100, Tom Tromey wrote:
> It works ok now precisely because the debug symbols don't include this
> information. Here it is without debuginfo:
>
> (gdb) p GDB<char>::even_harder<int> ('a')
> No symbol "GDB<char>" in current context.
> (gdb) p 'int GDB<char>::even_harder<int>' ('a')
> $1 = 97
This is bad but it is not a regression. Also I find such expression less
essential to GDB than to place a breakpoint there.
Thanks,
Jan
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: RFC: fix PR 12707
2013-01-18 14:35 ` Jan Kratochvil
@ 2013-01-18 15:04 ` Tom Tromey
2013-01-18 15:33 ` Jan Kratochvil
0 siblings, 1 reply; 15+ messages in thread
From: Tom Tromey @ 2013-01-18 15:04 UTC (permalink / raw)
To: Jan Kratochvil; +Cc: gdb-patches
>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
Jan> On Fri, 18 Jan 2013 15:30:43 +0100, Tom Tromey wrote:
>> It works ok now precisely because the debug symbols don't include this
>> information. Here it is without debuginfo:
>>
>> (gdb) p GDB<char>::even_harder<int> ('a')
>> No symbol "GDB<char>" in current context.
>> (gdb) p 'int GDB<char>::even_harder<int>' ('a')
>> $1 = 97
Jan> This is bad but it is not a regression. Also I find such expression less
Jan> essential to GDB than to place a breakpoint there.
Again, we are talking about different things.
That whole sub-thread was in the context of extending all symbols to
have the return type. If we do that, then we will regress some
expressions.
The status quo is that some symbols have return types and some do not.
This causes bugs. My argument is that uniformity is better.
Tom
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: RFC: fix PR 12707
2013-01-18 15:04 ` Tom Tromey
@ 2013-01-18 15:33 ` Jan Kratochvil
0 siblings, 0 replies; 15+ messages in thread
From: Jan Kratochvil @ 2013-01-18 15:33 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb-patches
On Fri, 18 Jan 2013 16:04:27 +0100, Tom Tromey wrote:
> The status quo is that some symbols have return types and some do not.
I understand what is happening there.
> This causes bugs. My argument is that uniformity is better.
From the user point of view it for most of the real world cases it currently
works better than with your patch.
Thanks,
Jan
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2013-01-18 15:33 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-14 19:31 RFC: fix PR 12707 Tom Tromey
2013-01-15 15:12 ` Pedro Alves
2013-01-15 15:32 ` Tom Tromey
2013-01-15 16:59 ` Jan Kratochvil
2013-01-15 17:05 ` Tom Tromey
2013-01-15 17:22 ` Jan Kratochvil
2013-01-17 21:25 ` Tom Tromey
2013-01-17 21:54 ` Jan Kratochvil
2013-01-17 21:59 ` Tom Tromey
2013-01-17 22:04 ` Jan Kratochvil
2013-01-17 22:33 ` Jan Kratochvil
2013-01-18 14:31 ` Tom Tromey
2013-01-18 14:35 ` Jan Kratochvil
2013-01-18 15:04 ` Tom Tromey
2013-01-18 15:33 ` Jan Kratochvil
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox