WAY faster linux gdb startup with gdb-add-index (~3s for browser_tests)

[Albert J. Wong (王重傑)]

If you sync past r144644, you'll now have build/gdb-add-index which is a simple script that adds a .gdb_index section into your binaries.  What this effectively does is write result of the "Reading symbols" step in gdb back into the binary so future invocations don't need to do this again.  What does this mean?  For me, "gdb browser_test" start time went from ~20s to ~3s.  My object files are on a tmpfs so YMMV.  However, it should yield speed increases for anyone debugging chromium on Linux.

So how do you use this thing?

If you are doing a static build, just do

  ./build/gdb-add-index out/Debug/browser_tests   # or whatever binary you want to debug.

If you are doing a components build, you have to index all the DSOs as well to get the full benefit.  From my testing, if you skip indexing your DSOs, you only get about 1/2 the speedup.  Luckily, you can just run this handy shell pipeline in addition to the above command to do this for you:

  ldd -d ./out/Debug/browser_tests  | grep "out/Debug/.*\.so" | cut -d '>' -f2 | cut -d ' ' -f2 | xargs -n1 ./build/gdb-add-index

Let me know if there any problems.

-Albert

[Dominic Hamon]

Does it take long to run? Perhaps it should be a post-link step for the build on Linux.

-Albert

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

[Albert J. Wong (王重傑)]

Unfortunately, it is a little more slow than starting gdb once without the index.  I was toying with getting a new gold which has a --gdb-index option to do it during link, but overall it seems simpler to let people just run the indexer manually as needed.

-Albert

[Darin Fisher]

Neat stuff!!

I've also found this to be handy:

(gdb) set auto-solib-add off

Then you can just load only the symbols for the shared libraries that you need.

-Darin

On Wed, Jun 27, 2012 at 7:06 PM, Albert J. Wong (王重傑) <ajw...@chromium.org> wrote:

-Albert

--

[Nico Weber]

Note: this means if your workflow is build-debug-change-rebuild-debug this won't help you.

Nico

[Albert J. Wong (王重傑)]

Yep. It's only useful if you run the debugger multiple times on the same binary like if you're debugging a bunch of renderers using --renderer-cmd-prefix.  It can also help if you are debugging multiple binaries that have overlapping shared libraries dependencies.

FYI, I just updated the script in r144835 to support binaries from the components w/o needing the shell pipeline.  All you should need to do now is run ./build/gdb-add-index out/Debug/[your binary].  The previous shell pipeline will be done automagically.

-Albert

[Scott Hess]

Can gdb just dump the darn thing on first run?

-scott


On Thu, Jun 28, 2012 at 4:42 PM, Albert J. Wong (王重傑)

[Albert J. Wong (王重傑)]

If you pop open the script, what it's actually doing *is* starting GDB and dumping things on the first run. Then it takes the dump and stuffs it back into the ELF object so the next run can just mmap it.

-Albert

[Reid Kleckner]

Right, but, would it be possible for me to write a .gdbinit file that checks each chrome DSO and adds the .gdbindex section to each one that's missing?  That would be awesome.  I might take a look at this, no promises.

[Vincent Scheib]

Seems this is part of the build now? haven't run gdb in ages but today noticed:

a) when starting gdb:

warning: Skipping deprecated .gdb_index section in /usr/local/google/home/scheib/c/src/out/Debug/browser_tests.
Do "set use-deprecated-index-sections on" before the file is read

 Hmm, should I be enabling use-deprecated-index-sections? My gdb --version: 7.7-gg5

b) when running build/gdb-add-index out/Debug/browser_tests all targets are skipped already having index.

Doc here is rusty: update: https://code.google.com/p/chromium/wiki/LinuxDebugging#Faster_startup

On Wed, Jun 27, 2012 at 7:06 PM, Albert J. Wong (王重傑) <ajw...@chromium.org> wrote:

-Albert

--

[Jeffrey Yasskin]

On Tue, May 6, 2014 at 1:25 PM, Vincent Scheib <sch...@chromium.org> wrote:
> Seems this is part of the build now? haven't run gdb in ages but today
> noticed:
> a) when starting gdb:
>>
>> warning: Skipping deprecated .gdb_index section in
>> /usr/local/google/home/scheib/c/src/out/Debug/browser_tests.
>> Do "set use-deprecated-index-sections on" before the file is read
>
> Hmm, should I be enabling use-deprecated-index-sections? My gdb --version:
> 7.7-gg5

I think something about it's not quite right: My gdb startup feels
slower since we started using -Wl,--gdb-index, even with
use-deprecated-index-sections.

I asked the internal gdb folks, and they said we ought to be using a
gold including the following commit, but that it's not merged to
binutils-2.24. I haven't gotten an answer yet about whether this would
cause problems for people using older versions of gdb.

commit ec673e648cf7b2fa6a03342b0bca3ed3855f002f
Author: Cary Coutant <ccou...@google.com>
Date: Tue Jan 28 15:35:47 2014 -0800

Add .gdb_index version 7 support.

> --

[Roland McGrath]

Older gdb versions should ignore a .gdb_index section of a newer
version than that gdb understands.
So it deprives users of such an older gdb of the benefits of
.gdb_index, but should not cause other problems.

[Jeffrey Yasskin]

Thanks Roland.

I've now tested the effect of using an old gold, and it turns out
that's not the problem:

Default Chrome gold, with `use-deprecated-index-sections`:
real 1m23.303s
user 1m10.370s
sys 0m4.430s

gold with the v7 patch:
real 1m17.556s
user 1m9.150s
sys 0m3.480s

Using https://code.google.com/p/chromium/codesearch/#chromium/src/build/gdb-add-index
patched to forcibly overwrite the section:
real 0m13.195s
user 0m6.440s
sys 0m2.160s

I've let the internal gdb/gold folks know.

[Antoine Labour]

On Tue, May 6, 2014 at 5:56 PM, Jeffrey Yasskin <jyas...@chromium.org> wrote:

Thanks Roland.

I've now tested the effect of using an old gold, and it turns out
that's not the problem:

Default Chrome gold, with `use-deprecated-index-sections`:
real    1m23.303s
user    1m10.370s
sys     0m4.430s

gold with the v7 patch:
real    1m17.556s
user    1m9.150s
sys     0m3.480s

Using https://code.google.com/p/chromium/codesearch/#chromium/src/build/gdb-add-index
patched to forcibly overwrite the section:
real    0m13.195s
user    0m6.440s
sys     0m2.160s

I've let the internal gdb/gold folks know.

Any update on this?

Current state for me is that:

- gdb startup still complains about deprecated index sections

- still slow to start, whether I specify 'set use-deprecated-index-sections on' or not

- gdb-add-index doesn't work because it says the section is already present.

If the gold-emitted index section doesn't work, can we disable this?

Antoine

On Tue, May 6, 2014 at 1:53 PM, Roland McGrath <mcgr...@chromium.org> wrote:
> Older gdb versions should ignore a .gdb_index section of a newer
> version than that gdb understands.
> So it deprives users of such an older gdb of the benefits of
> .gdb_index, but should not cause other problems.

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

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Jeffrey Yasskin]

On Thu, Jun 12, 2014 at 10:33 PM, Antoine Labour <pi...@google.com> wrote:
>
>
>
> On Tue, May 6, 2014 at 5:56 PM, Jeffrey Yasskin <jyas...@chromium.org>
> wrote:
>>
>> Thanks Roland.
>>
>> I've now tested the effect of using an old gold, and it turns out
>> that's not the problem:
>>
>> Default Chrome gold, with `use-deprecated-index-sections`:
>> real 1m23.303s
>> user 1m10.370s
>> sys 0m4.430s
>>
>> gold with the v7 patch:
>> real 1m17.556s
>> user 1m9.150s
>> sys 0m3.480s
>>
>> Using
>> https://code.google.com/p/chromium/codesearch/#chromium/src/build/gdb-add-index
>> patched to forcibly overwrite the section:
>> real 0m13.195s
>> user 0m6.440s
>> sys 0m2.160s
>>
>> I've let the internal gdb/gold folks know.
>
>
> Any update on this?

I filed http://crbug.com/374952 with the details, but apparently
nobody's had time to work on it.

[Albert J. Wong (王重傑)]

Catching up on this thread...if I understand correctly, this is being caused by -Wl,--gdb-index.

I think we should remove this linker flag.

When I first looked at this, Nico or Evan pointed out that having gold generate the index was equal to the time it took gdb to generate the index. Assuming that didn't change, for everyone not running the binary under a debugger, we just slowed their compile-build-run cycle. For anyone running with the debugger, we've given them 0 benefit unless they start up the binary more than once per build. While multiple runs is somewhat common -- especially if you're debugging the renderer -- it's still less common than build and run w/o debugger.

Having this be a post-process step seems more globally optimal and resilient to version skew between gold + the system gdb.

FYI, I also patched gdb-add-index so it can clobber badly written index files:

    https://codereview.chromium.org/330333005

-Albert

[Albert J. Wong (王重傑)]

FYI, her'es a CL for the flag removal.

https://codereview.chromium.org/335903002

[Kenneth Russell]

Sorry for the ignorant question -- what's the expected status of gdb
against debug Chromium builds? I'm seeing > 8 minute startup times on
an Ubuntu 12.04 workstation. gdb pauses for an extremely long time
even after it claims to have finished loading symbols.

Using component=shared_library and goma. Haven't done anything with
gdb configuration. I've never used gdb-add-index but it still used to
start in less than a minute.

Thanks,

-Ken



On Fri, Jun 13, 2014 at 12:26 PM, Albert J. Wong (王重傑)

[Kenneth Russell]

thakis@ suggested setting the GYP variable linux_use_debug_fission=0.
This massively sped up gdb's start time. Now it starts in about 1
minute 30 seconds instead of well over 8 minutes.

Should any default be changed here? I didn't watch the link time.

[Sunny]

Sorry for reviving this old thread. For some time now, the combination of clang, linux_use_debug_fission and gdb-add-index hasn't been working. However the combination of clang, linux_use_debug_fission and -Wl,--gdb-index works fine. I also measured gdb startup time for a chrome component build with the various options available:

1. clang + linux_use_debug_fission=0 + gdb-add-index script: ~4s

2. gcc + linux_use_debug_fission=1 + gdb-add-index script: ~6s

3. clang + linux_use_debug_fission=1 + no .gdb_index: ~22s

4. clang + linux_use_debug_fission=1 + gold --gdb-index: ~4s

Should we add a gyp/gn flag that adds "-Wl,--gdb-index" to ldflags? Or maybe we should find out why the gdb-add-index script doesn't work reliably any more?

Thanks!

- Sunny

>>>> >> email to chromium-dev+unsubscribe@chromium.org.

[Nico Weber]

Did you also mention linking speed perchance? Does -Wl,--gdb-index move the startup time just to link time, or does linking stay fast?

>>>> >> email to chromium-dev...@chromium.org.