* [Bug gdb/29104] GDB very slow running LLVM opt
2022-04-29 16:55 [Bug gdb/29104] New: GDB very slow running LLVM opt msebor at gmail dot com
@ 2022-04-29 18:01 ` tromey at sourceware dot org
2022-04-29 18:16 ` msebor at gmail dot com
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: tromey at sourceware dot org @ 2022-04-29 18:01 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29104
Tom Tromey <tromey at sourceware dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at sourceware dot org
--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
Could you "gdb -nx", then "maint time 1", and then do each step
separately? That would help narrow down where the performance
problem lies.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug gdb/29104] GDB very slow running LLVM opt
2022-04-29 16:55 [Bug gdb/29104] New: GDB very slow running LLVM opt msebor at gmail dot com
2022-04-29 18:01 ` [Bug gdb/29104] " tromey at sourceware dot org
@ 2022-04-29 18:16 ` msebor at gmail dot com
2022-04-29 19:07 ` tromey at sourceware dot org
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: msebor at gmail dot com @ 2022-04-29 18:16 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29104
--- Comment #2 from Martin Sebor <msebor at gmail dot com> ---
Like this? (The 25 second delay is after the Command execution time: line is
printed and before the rest of the output.)
$ gdb -nx -q /build/llvm-gcc/bin/opt
Reading symbols from /build/llvm-gcc/bin/opt...
(gdb) maint time 1
(gdb) r -S -instcombine x.ll
2022-04-29 12:10:34.658 - command started
Starting program: /ssd/build/llvm-gcc/bin/opt -S -instcombine x.ll
2022-04-29 12:10:34.737 - command finished
Command execution time: 0.070464 (cpu), 0.078909 (wall)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
; ModuleID = 'x.ll'
source_filename = "x.ll"
declare i64 @strlen(i8*)
define i64 @f(i8* %s) {
%n = call i64 @strlen(i8* noundef nonnull dereferenceable(1) %s)
ret i64 %n
}
[Inferior 1 (process 20983) exited normally]
(gdb) r -S -instcombine x.ll
2022-04-29 12:11:04.466 - command started
Starting program: /ssd/build/llvm-gcc/bin/opt -S -instcombine x.ll
2022-04-29 12:11:04.731 - command finished
Command execution time: 0.265862 (cpu), 0.265208 (wall)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
; ModuleID = 'x.ll'
source_filename = "x.ll"
declare i64 @strlen(i8*)
define i64 @f(i8* %s) {
%n = call i64 @strlen(i8* noundef nonnull dereferenceable(1) %s)
ret i64 %n
}
[Inferior 1 (process 20991) exited normally]
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug gdb/29104] GDB very slow running LLVM opt
2022-04-29 16:55 [Bug gdb/29104] New: GDB very slow running LLVM opt msebor at gmail dot com
2022-04-29 18:01 ` [Bug gdb/29104] " tromey at sourceware dot org
2022-04-29 18:16 ` msebor at gmail dot com
@ 2022-04-29 19:07 ` tromey at sourceware dot org
2022-04-29 19:21 ` msebor at gmail dot com
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: tromey at sourceware dot org @ 2022-04-29 19:07 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29104
--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Martin Sebor from comment #2)
> Like this? (The 25 second delay is after the Command execution time: line
> is printed and before the rest of the output.)
Normally it's better not to pass the file name on the command line,
and use "file", in case it's symbol reading that is slow.
Anyway here that doesn't seem to be an issue.
I guess you mean the first time that is printed?
> (gdb) r -S -instcombine x.ll
> 2022-04-29 12:10:34.658 - command started
> Starting program: /ssd/build/llvm-gcc/bin/opt -S -instcombine x.ll
> 2022-04-29 12:10:34.737 - command finished
> Command execution time: 0.070464 (cpu), 0.078909 (wall)
^^^ right here.
I forgot that "run" doesn't really DTRT with "maint time 1".
There's a bug about this somewhere.
Last time I had a problem like this it was due to a bad interaction
between "gcc -g3" and an lld/mold linker problem.
If that isn't your issue then there's no better approach than
profiling to see if the problem can be discovered. It's possible
there's just a very large CU and expanding it is slow, though 25
seconds seems a bit beyond.
Another possibility is expanding too many CUs.
"set debug dwarf-read 1" might uncover this.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug gdb/29104] GDB very slow running LLVM opt
2022-04-29 16:55 [Bug gdb/29104] New: GDB very slow running LLVM opt msebor at gmail dot com
` (2 preceding siblings ...)
2022-04-29 19:07 ` tromey at sourceware dot org
@ 2022-04-29 19:21 ` msebor at gmail dot com
2022-04-29 19:27 ` msebor at gmail dot com
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: msebor at gmail dot com @ 2022-04-29 19:21 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29104
--- Comment #4 from Martin Sebor <msebor at gmail dot com> ---
Created attachment 14086
--> https://sourceware.org/bugzilla/attachment.cgi?id=14086&action=edit
GDB debug dwarf-read output.
Attached is the output with "set debug dwarf-read 1". Does it narrow it down?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug gdb/29104] GDB very slow running LLVM opt
2022-04-29 16:55 [Bug gdb/29104] New: GDB very slow running LLVM opt msebor at gmail dot com
` (3 preceding siblings ...)
2022-04-29 19:21 ` msebor at gmail dot com
@ 2022-04-29 19:27 ` msebor at gmail dot com
2022-04-29 20:08 ` tromey at sourceware dot org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: msebor at gmail dot com @ 2022-04-29 19:27 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29104
--- Comment #5 from Martin Sebor <msebor at gmail dot com> ---
(In reply to Tom Tromey from comment #3)
>
> I guess you mean the first time that is printed?
I'm not sure I understand the question but to be clear: the 25 second delay
happens for each run command, so from each time the "Command execution time:"
line prints and until the "[Inferior 1 (process PID) exited normally]" line
appears.
I thought maybe the delay was caused by GDB reading the debug or symbol info
from the executable and the DSOs the file links with but then it should only
happen once (during the file command or the first run command), correct? Or
does it reload/reread everything on each run?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug gdb/29104] GDB very slow running LLVM opt
2022-04-29 16:55 [Bug gdb/29104] New: GDB very slow running LLVM opt msebor at gmail dot com
` (4 preceding siblings ...)
2022-04-29 19:27 ` msebor at gmail dot com
@ 2022-04-29 20:08 ` tromey at sourceware dot org
2022-04-29 22:38 ` msebor at gmail dot com
2022-05-09 17:31 ` tromey at sourceware dot org
7 siblings, 0 replies; 9+ messages in thread
From: tromey at sourceware dot org @ 2022-04-29 20:08 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29104
--- Comment #6 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Martin Sebor from comment #5)
> I'm not sure I understand the question but to be clear: the 25 second delay
> happens for each run command, so from each time the "Command execution
> time:" line prints and until the "[Inferior 1 (process PID) exited
> normally]" line appears.
Ok, I see. Thank you.
> I thought maybe the delay was caused by GDB reading the debug or symbol info
> from the executable and the DSOs the file links with but then it should only
> happen once (during the file command or the first run command), correct? Or
> does it reload/reread everything on each run?
I believe it reloads the shared libraries each time.
This is unfortunate... I've considered adding some hysteresis
here so gdb can reuse these when appropriate.
However, that won't help if the underlying libraries change a lot.
>From your run I see:
6 matches for "_hard" in buffer: dwarf-read-llvm.log
11:[dwarf-read] dwarf2_build_psymtabs_hard: Building psymtabs of objfile
/ssd/build/llvm-gcc/bin/opt ...
27:[dwarf-read] dwarf2_build_psymtabs_hard: Done building psymtabs of
/ssd/build/llvm-gcc/bin/opt
34:[dwarf-read] dwarf2_build_psymtabs_hard: Building psymtabs of objfile
/lib64/ld-linux-x86-64.so.2 ...
377:[dwarf-read] dwarf2_build_psymtabs_hard: Done building psymtabs of
/lib64/ld-linux-x86-64.so.2
653:[dwarf-read] dwarf2_build_psymtabs_hard: Building psymtabs of objfile
/ssd/build/llvm-gcc/bin/../lib/libLLVM-15git.so ...
2973:[dwarf-read] dwarf2_build_psymtabs_hard: Done building psymtabs of
/ssd/build/llvm-gcc/bin/../lib/libLLVM-15git.so
So I'd say that is the problem.
You might try gdb git master. It has a new DWARF scanner that is significantly
faster.
If any of these libraries have significant debuginfo but do not change often,
another
choice is "set index-cache on". This will cache an index after the first read.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug gdb/29104] GDB very slow running LLVM opt
2022-04-29 16:55 [Bug gdb/29104] New: GDB very slow running LLVM opt msebor at gmail dot com
` (5 preceding siblings ...)
2022-04-29 20:08 ` tromey at sourceware dot org
@ 2022-04-29 22:38 ` msebor at gmail dot com
2022-05-09 17:31 ` tromey at sourceware dot org
7 siblings, 0 replies; 9+ messages in thread
From: msebor at gmail dot com @ 2022-04-29 22:38 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29104
--- Comment #7 from Martin Sebor <msebor at gmail dot com> ---
GDB trunk indeed solves the problem! Thank you!
$ time ~/bin/gdb-trunk/bin/gdb --batch -nx -q -ex "r -S -instcombine x.ll"
/build/llvm-gcc/bin/opt
This GDB supports auto-downloading debuginfo from the following URLs:
<https://debuginfod.fedoraproject.org/>
Enable debuginfod for this session? (y or [n]) [answered N; input not from
terminal]
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
; ModuleID = 'x.ll'
source_filename = "x.ll"
declare i64 @strlen(i8*)
define i64 @f(i8* %s) {
%n = call i64 @strlen(i8* noundef nonnull dereferenceable(1) %s)
ret i64 %n
}
[Inferior 1 (process 133664) exited normally]
real 0m1.440s
user 0m10.096s
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug gdb/29104] GDB very slow running LLVM opt
2022-04-29 16:55 [Bug gdb/29104] New: GDB very slow running LLVM opt msebor at gmail dot com
` (6 preceding siblings ...)
2022-04-29 22:38 ` msebor at gmail dot com
@ 2022-05-09 17:31 ` tromey at sourceware dot org
7 siblings, 0 replies; 9+ messages in thread
From: tromey at sourceware dot org @ 2022-05-09 17:31 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29104
Tom Tromey <tromey at sourceware dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |13.1
Assignee|unassigned at sourceware dot org |tromey at sourceware dot org
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #8 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Martin Sebor from comment #7)
> GDB trunk indeed solves the problem! Thank you!
I'm glad to hear it.
I'm going to close this bug.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread