public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
* [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; 11+ 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] 11+ 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: Single Stepping into functions is very slow when not setting LD_BIND_NOW env variable bschindler at inf dot ethz dot ch
@ 2009-11-13 15:05 ` bschindler at inf dot ethz dot ch
0 siblings, 0 replies; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ 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 ` 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; 11+ 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] 11+ 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 ` 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; 11+ 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] 11+ 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 ` dje at google dot com
2012-05-01 17:49 ` dje at google dot com
` (7 subsequent siblings)
8 siblings, 0 replies; 11+ 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] 11+ messages in threadend of thread, other threads:[~2012-05-07 11:01 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-11-13 14:32 [Bug gdb/10952] New: Single Stepping into functions is very slow when not setting LD_BIND_NOW env variable bschindler at inf dot ethz dot ch
2009-11-13 15:05 ` [Bug gdb/10952] " bschindler at inf dot ethz dot ch
[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
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
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).