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] New: Single Stepping into functions is very slow when not setting LD_BIND_NOW env variable @ 2009-11-13 14:32 bschindler at inf dot ethz dot ch 2009-11-13 15:05 ` [Bug gdb/10952] " bschindler at inf dot ethz dot ch 0 siblings, 1 reply; 10+ messages in thread From: bschindler at inf dot ethz dot ch @ 2009-11-13 14:32 UTC (permalink / raw) To: gdb-prs (I'm not sure which values to fill out above (host, target and build triplet, so I'll describe below) I'm currently debugging paraview and very often, single stepping will cause gdb to stall for multiple seconds when stepping into a function call. Googling a bit revealed that setting LD_BIND_NOW can solve these problems. And here it did solve them I'm on a modern 8-core x86-64 system with more than enough ram. Kernel and user-space software is all in x86-64. Distribution is gentoo (no excessive flags) If there is anything I can do just let me know -- Summary: Single Stepping into functions is very slow when not setting LD_BIND_NOW env variable Product: gdb Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdb AssignedTo: unassigned at sourceware dot org ReportedBy: bschindler at inf dot ethz dot ch CC: gdb-prs at sourceware dot org 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 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 thread
end 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).