public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
* [Bug gdb/10952] Single Stepping into functions is very slow when not setting LD_BIND_NOW env variable
[not found] <bug-10952-4717@http.sourceware.org/bugzilla/>
@ 2012-05-01 17:07 ` dje at google dot com
2012-05-01 17:49 ` dje at google dot com
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: dje at google dot com @ 2012-05-01 17:07 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=10952
dje at google dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dje at google dot com
--- Comment #2 from dje at google dot com 2012-05-01 17:06:43 UTC ---
Data point: This is still an issue. One exampoe here took 30 seconds to get
through 1800 insns of dynsym resolving code.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug gdb/10952] Single Stepping into functions is very slow when not setting LD_BIND_NOW env variable
[not found] <bug-10952-4717@http.sourceware.org/bugzilla/>
2012-05-01 17:07 ` [Bug gdb/10952] Single Stepping into functions is very slow when not setting LD_BIND_NOW env variable dje at google dot com
@ 2012-05-01 17:49 ` dje at google dot com
2012-05-01 18:09 ` dje at google dot com
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: dje at google dot com @ 2012-05-01 17:49 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=10952
--- Comment #3 from dje at google dot com 2012-05-01 17:48:45 UTC ---
Some profiling data for the 30 seconds to step 1800 insns of dynsym resolving
code case.
gdb compiled with -g -pg -ftest-coverage -fprofile-arc.
This is with gdb 7.4.
gprof output:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ms/call ms/call name
35.22 6.97 6.97 18756 0.37 0.37 find_pc_sect_psymtab
8.84 8.72 1.75 1925 0.91 0.91 find_pc_sect_symtab
7.38 10.18 1.46 29385 0.05 0.12 dwarf2_read_abbrevs
7.33 11.63 1.45 167485647 0.00 0.00 read_unsigned_leb128
4.40 12.50 0.87 358406 0.00 0.00 cpname_parse
3.59 13.21 0.71 5015596 0.00 0.00 hash_continue
2.68 13.74 0.53 762409 0.00 0.00 strcmp_iw_ordered
2.27 14.19 0.45 15061184 0.00 0.00 dwarf2_lookup_abbrev
2.12 14.61 0.42 5946084 0.00 0.00 cpname_lex
1.54 14.92 0.31 d_print_comp
1.52 15.22 0.30 12193270 0.00 0.00 read_attribute_value
1.41 15.50 0.28 2013893 0.00 0.00 read_partial_die
1.16 15.73 0.23 10510160 0.00 0.00 dwarf_alloc_abbrev
1.06 15.94 0.21 29094 0.01 0.12 load_partial_dies
1.06 16.15 0.21 152021 0.00 0.00 msymbol_hash_iw
For find_pc_sect_psymtab, gcov shows this interesting tidbit:
85699863: 364: ALL_OBJFILE_PSYMTABS_REQUIRED (objfile, pst)
148591017: 365: if (!pst->psymtabs_addrmap_supported
62909784: 366: && pc >= pst->textlow && pc < pst->texthigh)
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug gdb/10952] Single Stepping into functions is very slow when not setting LD_BIND_NOW env variable
[not found] <bug-10952-4717@http.sourceware.org/bugzilla/>
2012-05-01 17:07 ` [Bug gdb/10952] Single Stepping into functions is very slow when not setting LD_BIND_NOW env variable dje at google dot com
2012-05-01 17:49 ` dje at google dot com
@ 2012-05-01 18:09 ` dje at google dot com
2012-05-02 9:55 ` palves at redhat dot com
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: dje at google dot com @ 2012-05-01 18:09 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=10952
--- Comment #4 from dje at google dot com 2012-05-01 18:08:49 UTC ---
Another data point for the same example:
gcov for symtab.c, find_pc_sect_symtab has this:
32582676: 1968: ALL_PRIMARY_SYMTABS (objfile, s)
-: 1969: {
206414: 1970: bv = BLOCKVECTOR (s);
206414: 1971: b = BLOCKVECTOR_BLOCK (bv, GLOBAL_BLOCK);
A case for having a list of the symtabs with block vectors not polluted by
symtabs without block vectors (or rather share theirs with the primary - the
include files) ?
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug gdb/10952] Single Stepping into functions is very slow when not setting LD_BIND_NOW env variable
[not found] <bug-10952-4717@http.sourceware.org/bugzilla/>
` (2 preceding siblings ...)
2012-05-01 18:09 ` dje at google dot com
@ 2012-05-02 9:55 ` palves at redhat dot com
2012-05-02 16:54 ` dje at google dot com
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: palves at redhat dot com @ 2012-05-02 9:55 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=10952
--- Comment #5 from Pedro Alves <palves at redhat dot com> 2012-05-02 09:54:38 UTC ---
Created attachment 6384
--> http://sourceware.org/bugzilla/attachment.cgi?id=6384
Install gdbarch_skip_solib_resolver on amd64 GNU/Linux
Looks like I'm sitting on this for 3 years already... (I'm pholklore)
Try this patch. For some reason, which I couldn't determine from looking at
the archives/history, amd64 doesn't install glibc_skip_solib_resolver. Looks
like an oversight. This short circuits a bunch of single-steps while resolving
plts.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug gdb/10952] Single Stepping into functions is very slow when not setting LD_BIND_NOW env variable
[not found] <bug-10952-4717@http.sourceware.org/bugzilla/>
` (3 preceding siblings ...)
2012-05-02 9:55 ` palves at redhat dot com
@ 2012-05-02 16:54 ` dje at google dot com
2012-05-03 15:36 ` palves at redhat dot com
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: dje at google dot com @ 2012-05-02 16:54 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=10952
--- Comment #6 from dje at google dot com 2012-05-02 16:53:32 UTC ---
Pedro, righto.
[Yes, I know you're pholkore. :-)]
Seems like an oversight to me.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug gdb/10952] Single Stepping into functions is very slow when not setting LD_BIND_NOW env variable
[not found] <bug-10952-4717@http.sourceware.org/bugzilla/>
` (4 preceding siblings ...)
2012-05-02 16:54 ` dje at google dot com
@ 2012-05-03 15:36 ` palves at redhat dot com
2012-05-03 15:37 ` palves at redhat dot com
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: palves at redhat dot com @ 2012-05-03 15:36 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=10952
Pedro Alves <palves at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2012-05-03
CC| |palves at redhat dot com
Ever Confirmed|0 |1
--- Comment #7 from Pedro Alves <palves at redhat dot com> 2012-05-03 15:35:29 UTC ---
http://sourceware.org/ml/gdb-patches/2012-05/msg00089.html
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug gdb/10952] Single Stepping into functions is very slow when not setting LD_BIND_NOW env variable
[not found] <bug-10952-4717@http.sourceware.org/bugzilla/>
` (5 preceding siblings ...)
2012-05-03 15:36 ` palves at redhat dot com
@ 2012-05-03 15:37 ` palves at redhat dot com
2012-05-07 11:00 ` cvs-commit at gcc dot gnu.org
2012-05-07 11:01 ` palves at redhat dot com
8 siblings, 0 replies; 10+ messages in thread
From: palves at redhat dot com @ 2012-05-03 15:37 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=10952
Pedro Alves <palves at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at sourceware |palves at redhat dot com
|dot org |
Target Milestone|7.1 |7.5
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug gdb/10952] Single Stepping into functions is very slow when not setting LD_BIND_NOW env variable
[not found] <bug-10952-4717@http.sourceware.org/bugzilla/>
` (6 preceding siblings ...)
2012-05-03 15:37 ` palves at redhat dot com
@ 2012-05-07 11:00 ` cvs-commit at gcc dot gnu.org
2012-05-07 11:01 ` palves at redhat dot com
8 siblings, 0 replies; 10+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2012-05-07 11:00 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=10952
--- Comment #8 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> 2012-05-07 10:59:30 UTC ---
CVSROOT: /cvs/src
Module name: src
Changes by: palves@sourceware.org 2012-05-07 10:59:26
Modified files:
gdb : ChangeLog
Log message:
Add PR number to ChangeLog entry.
2012-05-07 Pedro Alves <palves@redhat.com>
PR gdb/10952
* amd64-linux-tdep.c: Include glibc-tdep.h.
(amd64_linux_init_abi): Install glibc_skip_solib_resolver as
gdbarch_skip_solib_resolver callback.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.14213&r2=1.14214
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug gdb/10952] Single Stepping into functions is very slow when not setting LD_BIND_NOW env variable
[not found] <bug-10952-4717@http.sourceware.org/bugzilla/>
` (7 preceding siblings ...)
2012-05-07 11:00 ` cvs-commit at gcc dot gnu.org
@ 2012-05-07 11:01 ` palves at redhat dot com
8 siblings, 0 replies; 10+ messages in thread
From: palves at redhat dot com @ 2012-05-07 11:01 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=10952
Pedro Alves <palves at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #9 from Pedro Alves <palves at redhat dot com> 2012-05-07 11:00:59 UTC ---
Patch checked in.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug gdb/10952] Single Stepping into functions is very slow when not setting LD_BIND_NOW env variable
2009-11-13 14:32 [Bug gdb/10952] New: " bschindler at inf dot ethz dot ch
@ 2009-11-13 15:05 ` bschindler at inf dot ethz dot ch
0 siblings, 0 replies; 10+ messages in thread
From: bschindler at inf dot ethz dot ch @ 2009-11-13 15:05 UTC (permalink / raw)
To: gdb-prs
------- Additional Comments From bschindler at inf dot ethz dot ch 2009-11-13 15:05 -------
Thanks to some help from pholklore___ on #gdb on freenode, I was able to produce
some output.
I enabled:
set debug infrun 1
And the output is like this (the last 100 lines, there were way more than this,
but they were all the same)
infrun: stop_pc = 0x7ffff7deecb6
infrun: stepped into dynsym resolve code
infrun: resume (step=1, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 1703 [Thread 0x7ffff7e977c0 (LWP 1703)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x7ffff7deecb9
infrun: stepped into dynsym resolve code
infrun: resume (step=1, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 1703 [Thread 0x7ffff7e977c0 (LWP 1703)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x7ffff7deecbd
infrun: stepped into dynsym resolve code
infrun: resume (step=1, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 1703 [Thread 0x7ffff7e977c0 (LWP 1703)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x7ffff7deecc4
infrun: stepped into dynsym resolve code
infrun: resume (step=1, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 1703 [Thread 0x7ffff7e977c0 (LWP 1703)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x7ffff7deecc7
infrun: stepped into dynsym resolve code
infrun: resume (step=1, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 1703 [Thread 0x7ffff7e977c0 (LWP 1703)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x7ffff7deecc9
infrun: stepped into dynsym resolve code
infrun: resume (step=1, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 1703 [Thread 0x7ffff7e977c0 (LWP 1703)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x7ffff7deecce
infrun: stepped into dynsym resolve code
infrun: resume (step=1, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 1703 [Thread 0x7ffff7e977c0 (LWP 1703)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x7ffff7deecd2
infrun: stepped into dynsym resolve code
infrun: resume (step=1, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 1703 [Thread 0x7ffff7e977c0 (LWP 1703)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x7ffff7deecd3
infrun: stepped into dynsym resolve code
infrun: resume (step=1, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 1703 [Thread 0x7ffff7e977c0 (LWP 1703)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x7ffff7deecd4
infrun: stepped into dynsym resolve code
infrun: resume (step=1, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 1703 [Thread 0x7ffff7e977c0 (LWP 1703)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x7ffff7df45a2
infrun: stepped into dynsym resolve code
infrun: resume (step=1, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 1703 [Thread 0x7ffff7e977c0 (LWP 1703)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x7ffff7df45a5
infrun: stepped into dynsym resolve code
infrun: resume (step=1, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 1703 [Thread 0x7ffff7e977c0 (LWP 1703)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x7ffff7df45aa
infrun: stepped into dynsym resolve code
infrun: resume (step=1, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 1703 [Thread 0x7ffff7e977c0 (LWP 1703)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x7ffff7df45af
infrun: stepped into dynsym resolve code
infrun: resume (step=1, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 1703 [Thread 0x7ffff7e977c0 (LWP 1703)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x7ffff7df45b4
infrun: stepped into dynsym resolve code
infrun: resume (step=1, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 1703 [Thread 0x7ffff7e977c0 (LWP 1703)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x7ffff7df45b9
infrun: stepped into dynsym resolve code
infrun: resume (step=1, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 1703 [Thread 0x7ffff7e977c0 (LWP 1703)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x7ffff7df45be
infrun: stepped into dynsym resolve code
infrun: resume (step=1, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 1703 [Thread 0x7ffff7e977c0 (LWP 1703)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x7ffff7df45c3
infrun: stepped into dynsym resolve code
infrun: resume (step=1, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 1703 [Thread 0x7ffff7e977c0 (LWP 1703)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x7ffff7df45c7
infrun: stepped into dynsym resolve code
infrun: resume (step=1, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 1703 [Thread 0x7ffff7e977c0 (LWP 1703)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x7ffff7df45cb
infrun: stepped into dynsym resolve code
infrun: resume (step=1, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 1703 [Thread 0x7ffff7e977c0 (LWP 1703)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x7fffe7b8afd4
infrun: stepped into subroutine
infrun: inserting step-resume breakpoint at 0x7fffe7b8afe0
infrun: resume (step=0, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 1703 [Thread 0x7ffff7e977c0 (LWP 1703)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x7fffe7b8afe0
infrun: BPSTAT_WHAT_STEP_RESUME
infrun: stepped into subroutine
infrun: stop_stepping
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10952
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 10+ messages in threadend of thread, other threads:[~2012-05-07 11:01 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-10952-4717@http.sourceware.org/bugzilla/>
2012-05-01 17:07 ` [Bug gdb/10952] Single Stepping into functions is very slow when not setting LD_BIND_NOW env variable dje at google dot com
2012-05-01 17:49 ` dje at google dot com
2012-05-01 18:09 ` dje at google dot com
2012-05-02 9:55 ` palves at redhat dot com
2012-05-02 16:54 ` dje at google dot com
2012-05-03 15:36 ` palves at redhat dot com
2012-05-03 15:37 ` palves at redhat dot com
2012-05-07 11:00 ` cvs-commit at gcc dot gnu.org
2012-05-07 11:01 ` palves at redhat dot com
2009-11-13 14:32 [Bug gdb/10952] New: " bschindler at inf dot ethz dot ch
2009-11-13 15:05 ` [Bug gdb/10952] " bschindler at inf dot ethz dot ch
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).