Slowness of 'run' command in gdb with component debug build

[Xianzhu Wang]

(Copied from [chromium-dev] Proposal: we should stop supporting static debug builds thread)

My common scenario of debugging a rendering issue:

1. gdb out/Debug/content_shell

2. set some breakpoints

3. run --single-process [--run-layout-test] some/test

4. examine the execution

5. adjust breakpoints

repeat 3-5 until I address the issue.

With static build, step 1 takes about 50 seconds, and step 3 is fast. With component build, step 1 is fast, but step 3 takes about 50 seconds, and repeated step 3 takes almost the same amount of time in the same gdb session.

I'm using static debug build because repeating steps 3-5 several times in each gdb session is my common debugging scenario. Though step 1 is the same slow, it happens in each gdb session once only, and I can do other things while waiting for it. But one my debugging work starts, I don't want the slowness of step 3 to interrupt.

However, based on the comments in the "stop supported static debug builds" thread, people using component build didn't complaint about the slowness of gdb 'run'. So I'm wondering if what I encountered is just special to me (and if yes, what's your solution?), or just my debugging scenario is not common.

Thanks,

Xianzhu

[Dirk Pranke]

Regarding the slow initial startup, I think you can `set auto-solib-add mode off` in your .gdbinit to speed up the initial load, as it won't

load all of the symbols for shared libraries; the downside is that you then need to load symbols manually for the libraries you care about.

It's possible that might also speed up step 3 in a component build.

Though, if you're not rebuilding between each debugger run, I wouldn't expect the second and subsequent runs to be slow; the debugger should be reusing the symbols ...

-- Dirk

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Xianzhu Wang]

On Tue, Jul 26, 2016 at 4:32 PM, Dirk Pranke <dpr...@chromium.org> wrote:

Regarding the slow initial startup, I think you can `set auto-solib-add mode off` in your .gdbinit to speed up the initial load, as it won't

load all of the symbols for shared libraries; the downside is that you then need to load symbols manually for the libraries you care about. 

 

It's possible that might also speed up step 3 in a component build.

Thanks for the suggestion about auto-solib-add mode off. This allows selective load of dynamic libraries symbols which will take less time than loading all symbols. However, it requires manual load of symbols after the library is loaded, so the procedure would be complex: set a breakpoint after library load, run, load the symbol, set breakpoint at my desired place, continue. Anyway I will investigate more about this to find a feasible procedure.

Though, if you're not rebuilding between each debugger run, I wouldn't expect the second and subsequent runs to be slow; the debugger should be reusing the symbols ...

For me gdb unloads and reloads the symbols between runs in one gdb session. What should I do to prevent gdb from doing this?

[Yuta Kitamura]

On Wed, Jul 27, 2016 at 8:18 AM, Xianzhu Wang <wangx...@chromium.org> wrote:

(Copied from [chromium-dev] Proposal: we should stop supporting static debug builds thread)

My common scenario of debugging a rendering issue:

1. gdb out/Debug/content_shell

2. set some breakpoints

3. run --single-process [--run-layout-test] some/test

4. examine the execution

5. adjust breakpoints

repeat 3-5 until I address the issue.

With static build, step 1 takes about 50 seconds, and step 3 is fast. With component build, step 1 is fast, but step 3 takes about 50 seconds, and repeated step 3 takes almost the same amount of time in the same gdb session.

Have you tried "build/gdb-add-index out/Debug/content_shell" before starting gdb? This might help. However, it is known that gdb-add-index doesn't play nicely with debug fission, so you probably need to rebuild with a GN variable "use_debug_fission" set to false.

 

I'm using static debug build because repeating steps 3-5 several times in each gdb session is my common debugging scenario. Though step 1 is the same slow, it happens in each gdb session once only, and I can do other things while waiting for it. But one my debugging work starts, I don't want the slowness of step 3 to interrupt.

However, based on the comments in the "stop supported static debug builds" thread, people using component build didn't complaint about the slowness of gdb 'run'. So I'm wondering if what I encountered is just special to me (and if yes, what's your solution?), or just my debugging scenario is not common.

Thanks,

Xianzhu

--