maybe one of you cc'ed folks could take a look at this?

Aleks, do you see this?

tansell, do we need to pass some flag to set the DWO base path that we pass in gyp but don't in gn?

I've had the same issue when I'd start gdb in my home directory.

No problems when I run gdb from src, or out/Debug.

I was able to repro as well.

Adding @ukai to take a look, since this bug is a dupe of #404644 which he fixed in 2015.  Perhaps "-gsplit-dwarf" needs to be added in the new gn build system?

split-dwarf should be on by default in GN as well. I'm not in front of a linux build at the moment so can't confirm this, but maybe you can check?

Yeah, I see the flag on my build

I'm unsure why you are getting different behaviour with gn verse gyp. Have you tried comparing the compile and link command lines to see how they differ?

Plausible cause of this is when we started using "-fdebug-prefix-map=$absolute_path=." as an argument (https://crrev.com/fdca0741b22a4dddbf1808b8d0081651662b22c5).
https://chromium.googlesource.com/chromium/src/+/master/build/config/compiler/BUILD.gn#354

Do you see strange DW_AT_comp_dir with this?
% readelf --debug-dump=info /path/to/chromium/src/out/Debug/content_shell | grep DW_AT_comp_dir

> If I cd to the build directory (.e.g, chromium/src/out/Debug) before I 'attach' in gdb, the problem goes away.

and #9, I think it's working as intended?

or https://sourceware.org/gdb/onlinedocs/gdb/Source-Path.html ?

This is a regression compared to gyp, so if it's WAI, I'd like to know why.

Do you use -fdebug-prefix-map with gn?  not use -fdebug-prefix-map with gyp?

--fdebug-prefix-map=$absolute_path=. will drop $absolute_path (and replace it with .) in debug information.  It makes build output portable, independent of build directory.  It improves build performance better (with goma to improve cache hit rate. i.e. we could reuse the same output even when working directory doesn't matches).

when gdb looks up debug information, it doesn't know what directory it was built (i.e what directory ./ represents in debug information).  User should run gdb in the build directory (so ./ matches the directory), or tell gdb with dir command as described in https://sourceware.org/gdb/onlinedocs/gdb/Source-Path.html).

so, I think this is not gyp vs gn. It's just --fdebug-prefix-map flag usage.

+zforman who add --fdebug-prefix-map=$absolute_path=. in https://chromium.googlesource.com/chromium/src/+/fdca0741b22a4dddbf1808b8d0081651662b22c5

I question the value of making the debug build portable.  When does anyone ever run gdb on an executable that's not in the build location?

I think this is an unnecessary 'gotcha' for anyone trying to debug chrome for the first time.

It's not about making it portable, but about making it deterministic. That's important for goma cache hit rates etc.

szager: I do take Linux debug builds and run them in VMs with different WMs or what not. Though I usually don't allocate enough RAM to VMs to run gdb inside.

zforman@ was an intern at Google who worked on making the build deterministic. As thakis@ points out there is a lot of good reasons for wanting deterministic builds, such as goma cache hit rate, portability, etc.

However, it is kind of sucky that people run into this problem. Does it make sense for us to have a "launch-gdb" wrapper script to set various options which make sense for chromium development? (Could also do things like import the Chromium/Blink type pretty printing tools.)

I'm still interested to know why gn and gyp differ here though?

tansell: The reason for this is that when I added fdebug-prefix-map there was some reason (which I don't seem to have documented anywhere) why this wasn't straightforward to add to gyp. I think it was because gyp didn't have such easy access to absolute path as GN, but I might be completely misremembering.

At the time I think it was considered more useful to move onto other things, since GN is The Imminent Glorious Future, so we did.

Does "dir" actually work for y'all for this use case? It doesn't help for me, presumably because these are not source files

Issue 666278 has been merged into this issue.

 Issue 404644  has been merged into this issue.

Tim, could you please follow-up on this?

Can somebody please look at this issue?

I remember that this used to work with gyp and it does not work with gn, so this is a clear regression!

Are we supposed to copy over all our JS projects in the out directory just for gdb debugging?

https://sourceware.org/gdb/onlinedocs/gdb/Source-Path.html doesn't solve the issue?

Not for me. This command helped my gdb (started by QtCreator) to find the source code (otherwise it only showed assembly code), but the warnings do not disappear and I cannot inspect stack variables:

directory /myrepo/src/out/Debug

unless somebody has a plan to fix this, I'll introduce a gn flag for the reproducible build that is off by default. Buildbots can then enable that flag if they chose to, but for developers, the ability to use gdb is more important than better goma cache hit rates

When I originally made the fdebug-prefix-map change, I'm confident I tested that GDB still worked for debugging binaries produced (since that was a concern in changing the debug information). I'll try to reproduce this issue after work, and see why it is that the source path things that should resolve the issues... aren't resolving the issues.

CL here: https://codereview.chromium.org/2690943007

commented on the CL ... I agree that the default should work for developers and we should work around it on the bots, but we shouldn't land a CL that flips things but doesn't work around it on the bots :).

I was able to reproduce your problem, and after an (excessive) amount of effort, I was able to figure out a set of command line args that find the correct dwo files and source files:

gdb -d /path/to/chromium/src/out/Default \
    -iex "set debug-file-directory /path/to/chromium/src/out/Default" \
    /path/to/chromium/src/out/Default/chrome

This is absolutely more painful than I thought (I had thought only the source path needed to be set, which makes me wonder if I tested it properly the first time :)), but does seem to resolve your issue - as Tim pointed out last year, it might be worth making a gdb wrapper for this + e.g. loading pretty printing tools etc.

could we use this?

https://sourceware.org/gdb/onlinedocs/gdb/dotdebug_005fgdb_005fscripts-section.html

I'm doubtful, because I think that any solution that uses the .debug_gdb_scripts section would involve including non-deterministic stuff (read: an absolute path).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bf73428a02025c24fb2377b234eff6ca80bfbc32

commit bf73428a02025c24fb2377b234eff6ca80bfbc32
Author: jochen <jochen@chromium.org>
Date: Wed Feb 22 10:14:05 2017

Move stripping of debug symbols on linux behind a flag

BUG=603286
R=brettw@chromium.org

Review-Url: https://codereview.chromium.org/2690943007
Cr-Commit-Position: refs/heads/master@{#451971}

[modify] https://crrev.com/bf73428a02025c24fb2377b234eff6ca80bfbc32/build/config/compiler/BUILD.gn
[modify] https://crrev.com/bf73428a02025c24fb2377b234eff6ca80bfbc32/tools/mb/mb_config.pyl

I created  https://crbug.com/695706  about the possibility of using the .debug_gdb_scripts for auto-loading of helpful pretty-printing scripts and other things like that.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/050dbe550d14e99ad4e83093d4f4e79642b9edc3

commit 050dbe550d14e99ad4e83093d4f4e79642b9edc3
Author: dpranke <dpranke@chromium.org>
Date: Thu Apr 27 03:58:25 2017

Ensure that builders that use goma strip absolute paths by default.

This CL tweaks the MB configs so that any builder that is using goma
also sets strip_absolute_paths_from_debug_symbols_by_default=true.
This helps ensure that we get the best goma cache hit rate possible.
We don't just make the default equal to use_goma=true because doing
so may make it harder for devs to debug binaries, and we want devs
to be able to both debug binaries and use goma by default; the
tradeoff is that their builds are slightly slower.

R=thakis@chromium.org, jochen@chromium.org
BUG=603286,  712790 

Review-Url: https://codereview.chromium.org/2837863005
Cr-Commit-Position: refs/heads/master@{#467574}

[modify] https://crrev.com/050dbe550d14e99ad4e83093d4f4e79642b9edc3/build/config/compiler/BUILD.gn
[modify] https://crrev.com/050dbe550d14e99ad4e83093d4f4e79642b9edc3/tools/mb/mb_config.pyl

> I think I'd like to solve this by having "run" scripts that can make sure
> you're in the right directory before launching the binary, but I think this
> is probably the right compromise in the meantime.

We could probably do something like what I referred to above, i.e. ./run-gdb /path/to/chromium/src/out/Default/chrome running a script like the following (but probably converted to python :)):

---
gdb -d $(dirname $path) \
    -iex "set debug-file-directory $(dirname $path)" \
    $path

---

tansell pointed out (in https://bugs.chromium.org/p/chromium/issues/detail?id=695706) there's probably other stuff that a script like that could do.

Is this a reasonable compromise between "gdb just works" and "all the reasons why the CL caused this bug landed"?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/999471957dc5cf51048b0b344c58925a2954d452

commit 999471957dc5cf51048b0b344c58925a2954d452
Author: dpranke <dpranke@chromium.org>
Date: Thu Apr 27 20:32:33 2017

Revert of Ensure that builders that use goma strip absolute paths by default. (patchset #1 id:1 of https://codereview.chromium.org/2837863005/ )

Reason for revert:
Reverting in case this is related to the goma errors in https://crbug.com/716089

Original issue's description:
> Ensure that builders that use goma strip absolute paths by default.
>
> This CL tweaks the MB configs so that any builder that is using goma
> also sets strip_absolute_paths_from_debug_symbols_by_default=true.
> This helps ensure that we get the best goma cache hit rate possible.
> We don't just make the default equal to use_goma=true because doing
> so may make it harder for devs to debug binaries, and we want devs
> to be able to both debug binaries and use goma by default; the
> tradeoff is that their builds are slightly slower.
>
> R=thakis@chromium.org, jochen@chromium.org
> BUG=603286,  712790 
>
> Review-Url: https://codereview.chromium.org/2837863005
> Cr-Commit-Position: refs/heads/master@{#467574}
> Committed: https://chromium.googlesource.com/chromium/src/+/050dbe550d14e99ad4e83093d4f4e79642b9edc3

TBR=jochen@chromium.org,thakis@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=603286,  712790 

Review-Url: https://codereview.chromium.org/2843403004
Cr-Commit-Position: refs/heads/master@{#467769}

[modify] https://crrev.com/999471957dc5cf51048b0b344c58925a2954d452/build/config/compiler/BUILD.gn
[modify] https://crrev.com/999471957dc5cf51048b0b344c58925a2954d452/tools/mb/mb_config.pyl

Having a wrapper script which makes it easier to get a nice gdb setup seems like a good idea.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c7b0cf640eee349516d275dad1a00bd393ac8644

commit c7b0cf640eee349516d275dad1a00bd393ac8644
Author: dpranke <dpranke@chromium.org>
Date: Tue May 09 17:36:27 2017

Reland of Ensure that builders that use goma strip absolute paths by default. (patchset #1 id:1 of https://codereview.chromium.org/2843403004/ )

Reason for revert:
Relanding, since this was not a cause of the goma outage.

Original issue's description:
> Revert of Ensure that builders that use goma strip absolute paths by default. (patchset #1 id:1 of https://codereview.chromium.org/2837863005/ )
>
> Reason for revert:
> Reverting in case this is related to the goma errors in https://crbug.com/716089
>
> Original issue's description:
> > Ensure that builders that use goma strip absolute paths by default.
> >
> > This CL tweaks the MB configs so that any builder that is using goma
> > also sets strip_absolute_paths_from_debug_symbols_by_default=true.
> > This helps ensure that we get the best goma cache hit rate possible.
> > We don't just make the default equal to use_goma=true because doing
> > so may make it harder for devs to debug binaries, and we want devs
> > to be able to both debug binaries and use goma by default; the
> > tradeoff is that their builds are slightly slower.
> >
> > R=thakis@chromium.org, jochen@chromium.org
> > BUG=603286,  712790 
> >
> > Review-Url: https://codereview.chromium.org/2837863005
> > Cr-Commit-Position: refs/heads/master@{#467574}
> > Committed: https://chromium.googlesource.com/chromium/src/+/050dbe550d14e99ad4e83093d4f4e79642b9edc3
>
> TBR=jochen@chromium.org,thakis@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=603286,  712790 
>
> Review-Url: https://codereview.chromium.org/2843403004
> Cr-Commit-Position: refs/heads/master@{#467769}
> Committed: https://chromium.googlesource.com/chromium/src/+/999471957dc5cf51048b0b344c58925a2954d452

TBR=jochen@chromium.org,thakis@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=603286,  712790 

Review-Url: https://codereview.chromium.org/2873513003
Cr-Commit-Position: refs/heads/master@{#470369}

[modify] https://crrev.com/c7b0cf640eee349516d275dad1a00bd393ac8644/build/config/compiler/BUILD.gn
[modify] https://crrev.com/c7b0cf640eee349516d275dad1a00bd393ac8644/tools/mb/mb_config.pyl

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/67970ee192706eed7c080811732bab47383d636c

commit 67970ee192706eed7c080811732bab47383d636c
Author: dpranke <dpranke@chromium.org>
Date: Wed May 10 00:36:40 2017

Revert of Ensure that builders that use goma strip absolute paths by default. (patchset #1 id:1 of https://codereview.chromium.org/2873513003/ )

Reason for revert:
Speculatively reverting in case this is causing goma crashes (see crbug.com/720074)

Original issue's description:
> Reland of Ensure that builders that use goma strip absolute paths by default. (patchset #1 id:1 of https://codereview.chromium.org/2843403004/ )
>
> Reason for revert:
> Relanding, since this was not a cause of the goma outage.
>
> Original issue's description:
> > Revert of Ensure that builders that use goma strip absolute paths by default. (patchset #1 id:1 of https://codereview.chromium.org/2837863005/ )
> >
> > Reason for revert:
> > Reverting in case this is related to the goma errors in https://crbug.com/716089
> >
> > Original issue's description:
> > > Ensure that builders that use goma strip absolute paths by default.
> > >
> > > This CL tweaks the MB configs so that any builder that is using goma
> > > also sets strip_absolute_paths_from_debug_symbols_by_default=true.
> > > This helps ensure that we get the best goma cache hit rate possible.
> > > We don't just make the default equal to use_goma=true because doing
> > > so may make it harder for devs to debug binaries, and we want devs
> > > to be able to both debug binaries and use goma by default; the
> > > tradeoff is that their builds are slightly slower.
> > >
> > > R=thakis@chromium.org, jochen@chromium.org
> > > BUG=603286,  712790 
> > >
> > > Review-Url: https://codereview.chromium.org/2837863005
> > > Cr-Commit-Position: refs/heads/master@{#467574}
> > > Committed: https://chromium.googlesource.com/chromium/src/+/050dbe550d14e99ad4e83093d4f4e79642b9edc3
> >
> > TBR=jochen@chromium.org,thakis@chromium.org
> > # Skipping CQ checks because original CL landed less than 1 days ago.
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> > BUG=603286,  712790 
> >
> > Review-Url: https://codereview.chromium.org/2843403004
> > Cr-Commit-Position: refs/heads/master@{#467769}
> > Committed: https://chromium.googlesource.com/chromium/src/+/999471957dc5cf51048b0b344c58925a2954d452
>
> TBR=jochen@chromium.org,thakis@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=603286,  712790 
>
> Review-Url: https://codereview.chromium.org/2873513003
> Cr-Commit-Position: refs/heads/master@{#470369}
> Committed: https://chromium.googlesource.com/chromium/src/+/c7b0cf640eee349516d275dad1a00bd393ac8644

TBR=jochen@chromium.org,thakis@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=603286,  712790 

Review-Url: https://codereview.chromium.org/2874613002
Cr-Commit-Position: refs/heads/master@{#470444}

[modify] https://crrev.com/67970ee192706eed7c080811732bab47383d636c/build/config/compiler/BUILD.gn
[modify] https://crrev.com/67970ee192706eed7c080811732bab47383d636c/tools/mb/mb_config.pyl

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b1c56e14102683640d1cd69bcfac692875893fc6

commit b1c56e14102683640d1cd69bcfac692875893fc6
Author: dpranke <dpranke@chromium.org>
Date: Thu May 25 20:47:58 2017

Reland of Ensure that builders that use goma strip absolute paths by default. (patchset #1 id:1 of https://codereview.chromium.org/2874613002/ )

Reason for revert:
Reland #3 ...

Original issue's description:
> Revert of Ensure that builders that use goma strip absolute paths by default. (patchset #1 id:1 of https://codereview.chromium.org/2873513003/ )
>
> Reason for revert:
> Speculatively reverting in case this is causing goma crashes (see crbug.com/720074)
>
> Original issue's description:
> > Reland of Ensure that builders that use goma strip absolute paths by default. (patchset #1 id:1 of https://codereview.chromium.org/2843403004/ )
> >
> > Reason for revert:
> > Relanding, since this was not a cause of the goma outage.
> >
> > Original issue's description:
> > > Revert of Ensure that builders that use goma strip absolute paths by default. (patchset #1 id:1 of https://codereview.chromium.org/2837863005/ )
> > >
> > > Reason for revert:
> > > Reverting in case this is related to the goma errors in https://crbug.com/716089
> > >
> > > Original issue's description:
> > > > Ensure that builders that use goma strip absolute paths by default.
> > > >
> > > > This CL tweaks the MB configs so that any builder that is using goma
> > > > also sets strip_absolute_paths_from_debug_symbols_by_default=true.
> > > > This helps ensure that we get the best goma cache hit rate possible.
> > > > We don't just make the default equal to use_goma=true because doing
> > > > so may make it harder for devs to debug binaries, and we want devs
> > > > to be able to both debug binaries and use goma by default; the
> > > > tradeoff is that their builds are slightly slower.
> > > >
> > > > R=thakis@chromium.org, jochen@chromium.org
> > > > BUG=603286,  712790 
> > > >
> > > > Review-Url: https://codereview.chromium.org/2837863005
> > > > Cr-Commit-Position: refs/heads/master@{#467574}
> > > > Committed: https://chromium.googlesource.com/chromium/src/+/050dbe550d14e99ad4e83093d4f4e79642b9edc3
> > >
> > > TBR=jochen@chromium.org,thakis@chromium.org
> > > # Skipping CQ checks because original CL landed less than 1 days ago.
> > > NOPRESUBMIT=true
> > > NOTREECHECKS=true
> > > NOTRY=true
> > > BUG=603286,  712790 
> > >
> > > Review-Url: https://codereview.chromium.org/2843403004
> > > Cr-Commit-Position: refs/heads/master@{#467769}
> > > Committed: https://chromium.googlesource.com/chromium/src/+/999471957dc5cf51048b0b344c58925a2954d452
> >
> > TBR=jochen@chromium.org,thakis@chromium.org
> > # Not skipping CQ checks because original CL landed more than 1 days ago.
> > BUG=603286,  712790 
> >
> > Review-Url: https://codereview.chromium.org/2873513003
> > Cr-Commit-Position: refs/heads/master@{#470369}
> > Committed: https://chromium.googlesource.com/chromium/src/+/c7b0cf640eee349516d275dad1a00bd393ac8644
>
> TBR=jochen@chromium.org,thakis@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=603286,  712790 
>
> Review-Url: https://codereview.chromium.org/2874613002
> Cr-Commit-Position: refs/heads/master@{#470444}
> Committed: https://chromium.googlesource.com/chromium/src/+/67970ee192706eed7c080811732bab47383d636c

TBR=jochen@chromium.org,thakis@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=603286,  712790 

Review-Url: https://codereview.chromium.org/2909523002
Cr-Commit-Position: refs/heads/master@{#474794}

[modify] https://crrev.com/b1c56e14102683640d1cd69bcfac692875893fc6/build/config/compiler/BUILD.gn
[modify] https://crrev.com/b1c56e14102683640d1cd69bcfac692875893fc6/tools/mb/mb_config.pyl

Hi there,

I'm still observing issues with gdb, identical to issues merged into this one, such as  crbug.com/404644 , when debugging on real Chromebooks.

I suspect that this issue is also related to non-symbolized stack traces in logs as well (https://groups.google.com/a/chromium.org/forum/#!searchin/chromium-dev/backtrace/chromium-dev/gUC7DhA5AMU/xYKGRMqRAwAJ). 

My team and I (and others, it seems) have run into this issue, and the issue highlighted in my mailing list post, for the past ~6 months and would greatly appreciate any help or insight you all have. Thank you!

Hi again,

Has anyone on this bug had the chance to investigate this issue more, or happen to have any insight into it? Thank you! :)

Dirk, could your latest change have reintroduced this problem?

Dirk, could your latest change have reintroduced this problem?

I'm not aware of any changes that I've done (or that we've done in //build) recently that might have affected things.

Someone needs to take this over and dig into what's going on.

thakis@/hans@ - can someone on the compiler team look into this?

 Issue 772401  has been merged into this issue.

Hm.. I used the same exact gdb binary to debug chrome on Ubuntu Trusty and on Debian Testing.  Saw the warnings on Trusty but not Testing..  The environment must be different somehow.

Ok, for me this is happening because I was running Trusty in a VM and gdb was using the same search path for my guest system as the host, even though the absolute path on the guest system is different due to shared directories

Ok some things are going horribly wrong

1. strip_absolute_paths_from_debug_symbols is false by default, which causes the string "/usr/local/google/thomasanderson/..." to appear in every object file, executable, and shared library produced by the build.  This is not good for deterministic builds.  Also it means I'm having the problem from c#57.
2. When strip_absolute_paths_from_debug_symbols is manually set to true, it (necessarily) adds the string "/usr/local/google/thomasanderson/..." to the compiler flags.  This is not good for goma.
3. When strip_absolute_paths_from_debug_symbols=true, it sets gdb's search path to "./out/Debug", which means running gdb from the src directory is fine, but anywhere else will give the same "Could not find DWO CU" warnings.

+pcc is there any magic flag I can set to make debug info relative without using "fdebug-prefix-map"?

Nvm, I'm convinced a perfect solution is impossible.

The exact path that gdb checks is comp_dir/file_name: https://github.com/bminor/binutils-gdb/blob/master/gdb/dwarf2read.c#L10808
where comp_dir is DW_AT_comp_dir from .debug_info and file_name is DW_AT_GNU_dwo_name which is of the form "obj/...".

So no matter what we set DW_AT_comp_dir to, we can always run gdb from a directory that will cause comp_dir/file_name to be invalid.  I think the gdb wrapper that some folks suggested earlier is the only solution.

Same here. Last good version I have no such issue was 6.4.6 and the "Could not find DWO CU" appears at last in 6.5.116 =(. I'm using "is_debug=false v8_enable_backtrace=true is_component_build=true v8_use_external_startup_data=false" x64.release build.

Are there any known workaround for the issue?

In my particular case it was my fault building shared v8 with clang and then trying to link it on other system with g++. My issue is covered in mailing list - https://groups.google.com/forum/#!topic/v8-users/Jb1VSouy2Z0. Hope, it will help someone.

I submitted a DWARF std comment last year and it finally got assigned an issue:
http://dwarfstd.org/ShowIssue.php?issue=171130.2

Once the request makes it into the spec, all we need to do is wait (a few years) for all the tools to conform to the new standard and chromium can start using $ORIGIN in DW_AT_comp_dir, then this issue can finally be fixed once and for all.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3ae0e03b84c9bb0e143407387c3668600964851e

commit 3ae0e03b84c9bb0e143407387c3668600964851e
Author: Takuto Ikuta <tikuta@chromium.org>
Date: Fri May 18 06:10:40 2018

Enable strip_absolute_paths_from_debug_symbols for goma build on Linux

This is for compile cache sharing between users and bot using same build
config.

This will prevent gdb from finding symbols unless your pwd is the build
dir, or you follow the steps described in docs/linux_debugging.md added
in this CL.

Proposal docs.
https://docs.google.com/document/d/1OX4jY_bOCeNK7PNjVRuBQE9s6BQKS8XRNWGK8FEyh-E/edit?usp=sharing

Bug: crbug.com/439949, crbug.com/603286
Change-Id: I4a5a62a280bb40102866bcfa282e0993fb671755
Reviewed-on: https://chromium-review.googlesource.com/1055348
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#559814}
[modify] https://crrev.com/3ae0e03b84c9bb0e143407387c3668600964851e/build/config/compiler/BUILD.gn
[modify] https://crrev.com/3ae0e03b84c9bb0e143407387c3668600964851e/docs/linux_debugging.md
[add] https://crrev.com/3ae0e03b84c9bb0e143407387c3668600964851e/tools/gdb/gdbinit

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/52fcb20fa679015d756ad9ec9a5e4a217894ae4c

commit 52fcb20fa679015d756ad9ec9a5e4a217894ae4c
Author: Takuto Ikuta <tikuta@chromium.org>
Date: Thu May 24 21:19:22 2018

Fix gdbinit to handle dwo files correctly

We need to tell the location of dwo files to gdb too, to load debug information
correctly.
Reported in
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/Y_2aYS6_DXA/qQCeeznpCwAJ

I also changed to use event handler for newly loaded objfiles.

Bug: crbug.com/439949, crbug.com/603286
Change-Id: Ib0b52c5553578333cd0dd44f11a9117345622844
Reviewed-on: https://chromium-review.googlesource.com/1068785
Reviewed-by: Aleks Totic <atotic@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
Cr-Commit-Position: refs/heads/master@{#561632}
[modify] https://crrev.com/52fcb20fa679015d756ad9ec9a5e4a217894ae4c/tools/gdb/gdbinit

No one complains about enabling -fdebug-prefix-map by default.
I think this is fixed.

Sorry for reviving this, but I am not sure whether this is fixed.
I observe the issue as in #1 and it goes away if I cd into a build directory.

My setup is 

gn gen out/GdbDebug --args='target_os="linux" use_goma=true use_jumbo_build=true enable_nacl=false is_debug=true symbol_level=2 remove_webcore_debug_symbols=true'

ninja -g -C out/GdbDebug -j2000 -l20 chrome

gdb out/GdbDebug/chrome


As a result I can't see the source code in gdb.

vitalii: Did you add `source path/to/chromium/src/tools/gdb/gdbinit` to your ~/.gdbinit as documented on https://chromium.googlesource.com/chromium/src/+/master/docs/linux_debugging.md#source-level-debug-with-fdebug_compilation_dir ?