"frame variable", "source list", etc. fail to produce the expected output

[llvmbot]

Bugzilla Link	28826
Version	3.9
OS	Linux
Reporter	LLVM Bugzilla Contributor
CC	@adrian-prantl,@dwblaikie,@echristo,@tberghammer

Extended Description

I'm trying to switch from gdb to lldb, but I can't get the latter to work. I can attach to a process, stop it, see the backtrace, but I can't do anything else with it. Source code can't be displayed, variables aren't displayed and can't be accessed:

(lldb) b blink::Document::setDesignMode Breakpoint 1: where = chrome`blink::Document::setDesignMode(WTF::String const&) + 27, address = 0x000055cf108aaf8b (lldb) c Process 15124 resuming Process 15124 stopped

• thread #​1: tid = 15124, 0x000055cf108aaf8b chromeblink::Document::setDesignMode(WTF::String const&) + 27 at Document.cpp:4634, name = 'chrome', stop reason = breakpoint 1.1 frame #​0: 0x000055cf108aaf8b chromeblink::Document::setDesignMode(WTF::String const&) + 27 at Document.cpp:4634 (lldb) expr this error: invalid use of 'this' outside of a non-static member function (lldb) frame variable (lldb) f frame #​0: 0x000055cf108aaf8b chromeblink::Document::setDesignMode(WTF::String const&) + 27 at Document.cpp:4634 (lldb) source info Lines found in modulechrome [0x000055cf108aaf8b-0x000055cf108aaf91): ./out/Default/../../third_party/WebKit/Source/core/dom/Document.cpp:4634:21 (lldb) source list (lldb)

And once I detach from the process, I can't even reattach to anything else until lldb is restarted:

(lldb) c Process 15124 resuming (lldb) detach Process 15124 detached (lldb) attach -p 15124 error: no error returned from Target::Attach, and target has no process (lldb) attach -p 15005 error: no error returned from Target::Attach, and target has no process

Everything works in gdb. There's something fundamentally wrong with this stuff since the very basic functionality seems to be broken. Am I missing something required for lldb to work properly? I'd be happy to provide more information if needed.

Versions: Latest lldb compiled from trunk, latest Chrome compiled from trunk (tried launching with --allow-sandbox-debugging, --no-sandbox, and both). OS: Ubuntu 16.04.1

[llvmbot]

When you are stopped in your function, can you view those variables using "frame variable"? What does the output of the following show?:

(lldb) frame variable value newValue

No problem with these:

(lldb) frame variable value newValue (const WTF::String &) value = 0x00007fff50147350: { m_impl = { m_ptr = 0x0000228b19c0a0d0 } } (bool) newValue = false

Jim also said that you can disable this feature:

(lldb) settings set target.experimental.inject-local-vars false

then try your expressions and let us know how it works?

(lldb) p this warning: (x86_64) /home/name/src/chromium/src/out/deb/./libblink_core.so 0x1fdf430016d550: DW_AT_specification(0x000025be) has no decl

error: invalid use of 'this' outside of a non-static member function (lldb) p this->htmlBodyElement() error: invalid use of 'this' outside of a non-static member function (lldb) p (blink::Document*)(this) error: invalid use of 'this' outside of a non-static member function

Please note that these expressions work when chrome is recompiled without -gsplit-dwarf, which suggests it might have something to do with the split DWARF support (although it might be a red herring as well, no clue).

[llvmbot]

The whole reason we sometimes need to inject local variables is you might be stopped in a class that has an instance variable named "foo":

class A { int foo; void doSomething() { int foo; // local var that shadows the member variable "foo" printf(...., foo); // Stop here } };

So if we stop and run an expression in A::doSomething(), and we type the following expression:

(lldb) p foo

If we don't inject local variables using the $lldb_local_vars trick, we will also display A::foo. Why? Because we pretend our expression is run in the context of the class, and in this case Clang already knows about the class, so when it sees the "foo" in the expression, it already knows that that is a member variable of the class and it never asks LLDB to find what "foo" is. If it does ask us what "foo" is, we would tell it it was a local variable, but it won't ask. The $lldb_local_vars trick is supposed to fix that and make clang prefer the local variable over the member variable, but it falls down in many places, and your case seems to be one such reason.

[llvmbot]

Actually I am wrong about needing the declaring $__lldb_local_vars namespace. I guess we just inject it as:

using $__lldb_local_vars::argc;
using $__lldb_local_vars::argv;

And then when we do lookup on the "$__lldb_local_vars" token, we say "that is a namespace" and then we know to look inside of the magic namespace for any local variables. After speaking with Jim Ingham, it seems that we probably had trouble finding one of more of your local variables. The ones in your expression were:

using $lldb_local_vars::value; using $lldb_local_vars::newValue;

When you are stopped in your function, can you view those variables using "frame variable"? What does the output of the following show?:

(lldb) frame variable value newValue

Jim also said that you can disable this feature:

(lldb) settings set target.experimental.inject-local-vars false

then try your expressions and let us know how it works?

[llvmbot]

So someone had added a feature to the expression parser where all local variables would be mentioned in side of the namespace named "$__lldb_local_vars". So if you were in "main(int argc, char **argv)" you would have to locals:

namespace $__lldb_local_vars { int argc; char **argv; }

And then you would add this to the expression code:

void
$lldb_expr(void *$__lldb_arg)
{
using $lldb_local_vars::argc; using $__lldb_local_vars::argv; .... expression text here .... }

But something is messing up and it isn't creating this __lldb_local_vars namespace. The local variables are added by a function named AddLocalVariableDecls() in ExpressionSourceCode.cpp, and that is what is showing up above. It looks like there is a problem in the other place that needs to create the namespace, which is in ClangExpressionDeclMap::FindExternalVisibleDecls() in ClangExpressionDeclMap.cpp. Something is going wrong in that code that is failing to produce the declaration of the variables, or the text below:

namespace $__lldb_local_vars { int argc; char **argv; }

But AddLocalVariableDecls() in ExpressionSourceCode.cpp is emitting the using declarations:

using $__lldb_local_vars::argc;
using $__lldb_local_vars::argv;

If you can trace through why code is not emitting the namespace declaration, then you might get the root cause of the problem.

[llvmbot]

Expression failure log Please find attached the requested log.

What kind of context are you stopped in? Just in a normal method? Constructor? Is the function default created by the language (not in your code or in as "= default;"?

It's a regular method from Blink: blink::Document::setDesignMode - nothing unusual about it AFAICT.

[llvmbot]

Gotcha, we need to fix that bug by looking into it then. Sean Callanan might be able to help you determine what is going on. Before you evaluate your expression, enable logging:

(lldb) log enable -f /tmp/expr.txt lldb expr (lldb) p this warning: (x86_64) /home/name/src/chromium/src/out/deb/./libblink_core.so 0x1fdf430016d550: DW_AT_specification(0x000025be) has no decl

error: use of undeclared identifier '$lldb_local_vars' error: use of undeclared identifier '$lldb_local_vars' (lldb) log disable lldb

then attach expr.txt. It might tell us more about what is happening. What kind of context are you stopped in? Just in a normal method? Constructor? Is the function default created by the language (not in your code or in as "= default;"?

[llvmbot]

You must use the expression parser and not frame variable if you wish to call functions. The last three things you had will need to be:

(lldb) p this->htmlBodyElement() (lldb) p this->executingWindow (lldb) p (blink::Document*)(this)

It doesn't work, throws the very same set of errors as with "expr":

(lldb) p this warning: (x86_64) /home/name/src/chromium/src/out/deb/./libblink_core.so 0x1fdf430016d550: DW_AT_specification(0x000025be) has no decl

error: use of undeclared identifier '$lldb_local_vars' error: use of undeclared identifier '$lldb_local_vars' error: invalid use of 'this' outside of a non-static member function (lldb) p this->htmlBodyElement() error: use of undeclared identifier '$lldb_local_vars' error: use of undeclared identifier '$lldb_local_vars' error: invalid use of 'this' outside of a non-static member function (lldb) p this->executingWindow error: use of undeclared identifier '$lldb_local_vars' error: use of undeclared identifier '$lldb_local_vars' error: invalid use of 'this' outside of a non-static member function (lldb) p (blink::Document*)(this) error: use of undeclared identifier '$lldb_local_vars' error: use of undeclared identifier '$lldb_local_vars' error: invalid use of 'this' outside of a non-static member function

"frame variable" might not be dynamically typing your variables for you, which might be why it might not be able to find "executingWindow" in this. You can change this setting:

(lldb) set set target.prefer-dynamic-value no-run-target

It's already set like this: (lldb) settings show target.prefer-dynamic-value target.prefer-dynamic-value (enum) = no-run-target

[llvmbot]

You must use the expression parser and not frame variable if you wish to call functions. The last three things you had will need to be:

(lldb) p this->htmlBodyElement() (lldb) p this->executingWindow (lldb) p (blink::Document*)(this)

"frame variable" might not be dynamically typing your variables for you, which might be why it might not be able to find "executingWindow" in this. You can change this setting:

(lldb) set set target.prefer-dynamic-value no-run-target

[llvmbot]

The convenient expression evaluator is one of the main reasons why I'd like to switch from gdb to lldb. My use case requires that I can call functions (including static ones out of the frame's scope) or cast types, can I do it in lldb without using the "expr" command?

From the blink::Document::setDesignMode example:

gdb: (gdb) p this $1 = (blink::Document ) 0x3939fd2224e0 (gdb) p this->executingWindow $2 = {blink::LocalDOMWindow (blink::Document const)} 0x7f21493cb9b0 <blink::Document::executingWindow()> (gdb) p this->executingWindow() $3 = (blink::LocalDOMWindow ) 0x85915a4c2e0 (gdb) p this->htmlBodyElement There is no member or method named htmlBodyElement. (gdb) p ((blink::HTMLDocument)this)->htmlBodyElement $4 = {blink::HTMLBodyElement (const blink::HTMLDocument const)} 0x7f2149664e60 <blink::HTMLDocument::htmlBodyElement() const> (gdb) p ((blink::HTMLDocument)this)->htmlBodyElement() $5 = (blink::HTMLBodyElement *) 0x3939fd223240

lldb: (lldb) fr va this (blink::HTMLDocument ) this = 0x000016ec3d5424e0 (lldb) fr va this->htmlBodyElement error: "htmlBodyElement" is not a member of "(blink::HTMLDocument ) this" (lldb) im loo -t blink::HTMLDocument Best match found in /home/name/src/chromium/src/out/deb/./libblink_core.so: id = {0x20ce2d00013559}, name = "HTMLDocument", qualified = "blink::HTMLDocument", byte-size = 2928, decl = HTMLDocument.h:34, compiler_type = "class HTMLDocument : public blink::Document { (...) blink::HTMLBodyElement htmlBodyElement() const; (...) }" (lldb) fr va this->htmlBodyElement() error: "htmlBodyElement()" is not a member of "(blink::HTMLDocument ) this" (lldb) fr va this->executingWindow error: "executingWindow" is not a member of "(blink::HTMLDocument ) this" (lldb) fr va (blink::Document)(this) error: no variable named '(blink::Document*)(this)' found in this frame

[tberghammer]

It is a known issue that "expr this" (and similar "expr" commands) does not work with chrome and it is a fairly complicated issue to fix but using "fr va this" should gave you the same result and it should work much better at the moment and it is faster as well (and will always be).

The difference between the 2 command is that in case of "expr this" LLDB tries to pars it as a C++ expression what require it to understand pretty much every part of the debug info inside chrome while in case of "fr va this" it looks for a local variable named "this" what require only understanding of the current frame and the type of "this".

The "fr va" command is fairly powerful so I expect that you will be able to do almost everything using that. A few supported example: fr va this fr va *this fr va this->foo fr va this->foo[0]->bar

Note: "fr va" is the abbreviation for "frame variable"

[llvmbot]

Thanks a lot for the fix! I've rebuilt lldb from the trunk and I can confirm that "adding range" errors are gone. However, this is the only change I'm seeing: "frame variable" you mentioned had already worked before the commit (with lldb launched from the chrome's source directory). I think the expression evaluation failure is the critical problem here:

(lldb) expr this warning: (x86_64) /home/name/src/chromium/src/out/deb/./libblink_core.so 0x1fdf430016d550: DW_AT_specification(0x000025be) has no decl

error: use of undeclared identifier '$lldb_local_vars' error: use of undeclared identifier '$lldb_local_vars' error: invalid use of 'this' outside of a non-static member function <<<

I thought this was somehow related to "adding range" errors (since removing "-gsplit-dwarf" from the chrome build both fixed those errors AND made expression evaluation work), but now it looks like it's something else and another fix is needed. Maybe the warning printed above provides a clue about the culprit? Once expression evaluation works, it'll be possible to debug chrome built with the "-gsplit-dwarf" parameter, and I'll be able to add "-fstandalone-debug" to fix further errors and see how that works.

[tberghammer]

Sorry for the long delay but Today I manage to submit https://reviews.llvm.org/rL281595 what should fix the main problem with split dwraf support.

After that CL I was able to display local variables using the "frame variable" (or "fr va") command while debugging chrome but I still see a few smaller issues:

• Sometime "frame variable" only displays the full set of local variables when executed the 2nd (or ongoing) time
• Expression evaluation fails with a strange error even for trivial expressions

[llvmbot]

Let me write a quick summary for anyone having similar problems and stumbling upon this bug as there are a few issues and it's easy to lose track of the specific workarounds:

1) LLDB can attach to chrome, but doesn't show any variables or any source code --- worked around by running lldb from the source root. 2) LLDB can attach to chrome, displays source code and most variables, but throws numerous "adding range" errors, and trivial things like "expr this" fail to work --- worked around by recompiling the executable without -gsplit-dwarf.

Hmm - and nothing worked here? LLDB was never able to find the .dwo files? (even if you ran lldb from the directory where the executable is in the build tree, etc?)

As a workaround you could try to remove that debug-path-map thing. I'm sure it's there for a reason & it might break other things, but you might be able to at least get your situation working even if it wouldn't work in full generality.

I restored "-gsplit-dwarf" and chucked out "-fdebug-prefix-map". The only difference is that I can now run lldb from anywhere and it'll recognize variables and print source code, so it works around problem #​1, but issue #​2 persists regardless of where I'm running lldb from. #​2 is a bug in the split dwarf support in lldb, so I'll just keep my fingers crossed for Tamas and I hope he'll be able to come up with some solution :-)

I also realized why I'd never hit problem #​1 in gdb: gyp builds don't set the --fdebug-prefix-map flag. I'd always used gyp builds and I've switched to gn just recently. Here's a relevant Chromium ticket where they discuss a similar problem with gdb: https://bugs.chromium.org/p/chromium/issues/detail?id=603286

[llvmbot]

Dave I agree with all that you said. I would like to get something into the DWARF standard at some point so that we can have debug info that can move around. It would be great if source locations were relocatable by having N paths stored somewhere in the DWARF could easily be modified. Also allowing support DWARF files like the DWO files to be packaged up with the main DWARF file in some package like fashion so they can all travel together would be great.

On MacOSX, we have the dSYM bundle which is just a directory that can contain not only the main DWARF file, but extra files. We currently package up a XML plist inside of some dSYM bundles that say "replace all source paths that start with "/a/b/c" with "/q/r/s". LLDB knows how to read this information (actually the SymbolVendorMacOSX does) and it causes us to change all source paths as they are created so that the debug info makes sense.

If the DWO case, a directory could be used. For the DWARF that was:

<0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_stmt_list : 0x0 <10> DW_AT_GNU_dwo_name: obj/chrome/chrome_initial/chrome_exe_main_aura.dwo <14> DW_AT_comp_dir : ./out/Default <18> DW_AT_GNU_dwo_id : 0x2e0b001d737b2f0a <20> DW_AT_GNU_addr_base: 0x0 <24> DW_AT_low_pc : 0xd9e7a0 <2c> DW_AT_high_pc : 0x28 Maybe something like: chrome.dwo/chrome chrome.dwo/out/Default/obj/chrome/chrome_initial/chrome_exe_main_aura.dwo And if the main DWARF binary exists inside of a package like "chrome.dwo", we can infer any relative locations to be relative to the chrome.dwo directory. Regardless, this is a great problem for us all to solve correctly at some point in the future. I agree for now we should make things work as well as we can, and we will be happy to accept and DWO patches that make LLDB work at least as well as GDB. This means fixing the relative path stuff, and fixing the DWO support so that the address range issue doesn't happen.

[dwblaikie]

My 2 cents are that users should never have to run the debugger from a specific directory,

Sure - was just looking to see if there were any workarounds at least - and to possibly understand a bit more about GDB and LLDB's search path logic.

so hopefully we can fix any relative issues in a sane way that doesn't rely on saying "I guess I can check around X to see if I can find ./relative/path/to/Y".

I'm not sure this follows from the previous - if X is the executable, I think it's probably pretty useful to be able to resolve .dwo paths relative to that in some set of cases, to make it easy to move build directories around (so I can, say, send a reproduction to a friend that they can use/debug). It seems unfortunate when files can't be moved around in a filesystem and keep working. (granted, source code is hard to fix - but I'd expect there to be some option to have a way to specify search paths for source too - again, I'd imagine a distributed build system would hit this)

Or I added the twelve locations that GDB seems to look for stuff to LLDB and now it can debug things until someone comes along with 13th way.

I don't think it's that specific - it's not like a hardcoded set of paths at least in this case. It's some heuristical, for sure. But hence the desire for someone to go look at/talk to someone on GDB to understand the full set of ways it resolves .dwo paths so we could have a chat about what might suit both LLDB and GDB design goals, etc. See what's reasonable. Maybe even enshrine some of that in the DWARF standard.

If we are doing distributed builds, lets make all of the tools able to correctly link up the debug info in the end so we don't end up with non rooted relative paths where we have to guess the root.

Except in ELF land linking is a DWARF agnostic step - linkers have no knowledge of debug info so no real ability to fix/change/rewrite it. (& it wouldn't solve the portability issue of being able to move a build tree around - download a pre-existing build+debug info and just use it, etc)

And I am just speculating about why Chrome's build uses this relative path setting in the first place - it'd be helpful to understand what their goals are in using that feature. My guesses are a distributed build and a way to make the build path-agnostic. But I could be wrong and/or there could be other reasons.

Hard to really figure out the solution without understanding the customer needs/use cases. Not sure if/when/how we'd rope in the right people from Chrome to have that discussion (or from GDB to have that other discussion), though.

[llvmbot]

My 2 cents are that users should never have to run the debugger from a specific directory, so hopefully we can fix any relative issues in a sane way that doesn't rely on saying "I guess I can check around X to see if I can find ./relative/path/to/Y". Or I added the twelve locations that GDB seems to look for stuff to LLDB and now it can debug things until someone comes along with 13th way.

If we are doing distributed builds, lets make all of the tools able to correctly link up the debug info in the end so we don't end up with non rooted relative paths where we have to guess the root.

Is there any way we can fixup a DW_AT_comp_dir in .o file DWARF with the correct path? Could this be done by the linker when doing distributed build linking somehow? Does linking always occur on the main build machine, or are link phases also distributed?

Barring pulling linker tricks that is there new DWARF we can add, or addendums to the DW_AT_GNU_dwo_name support that say something like "if you have a DW_AT_GNU_dwo_name that is a relative path, and the DW_AT_comp_dir is also relative, here is how you would resolve the final path? Something extra in the DWARF in the linked executable that can help us come up with a truth would be a much and sustainable solution. It seems very fragile to try to do things in any other way.

[dwblaikie]

Oh, sorry - those flags aren't mutually exclusive. If you have -gsplit-dwarf working (ie: you're not getting the errors about missing .dwo files)

The thing is, I don't: it's only after I removed -gsplit-dwarf that things like "expr this" started to work in lldb.

Ah, right. Thanks for correcting/reminding me.

Let me write a quick summary for anyone having similar problems and stumbling upon this bug as there are a few issues and it's easy to lose track of the specific workarounds:

1) LLDB can attach to chrome, but doesn't show any variables or any source code --- worked around by running lldb from the source root. 2) LLDB can attach to chrome, displays source code and most variables, but throws numerous "adding range" errors, and trivial things like "expr this" fail to work --- worked around by recompiling the executable without -gsplit-dwarf.

Hmm - and nothing worked here? LLDB was never able to find the .dwo files? (even if you ran lldb from the directory where the executable is in the build tree, etc?)

As a workaround you could try to remove that debug-path-map thing. I'm sure it's there for a reason & it might break other things, but you might be able to at least get your situation working even if it wouldn't work in full generality.

3) LLDB can attach to chrome, displays source code and most variables, "expr this" works as expected, but "incomplete definition" errors are displayed when printing a bracktrace and the debugger terminates when trying to do things like "expr this->method" --- can be worked around by recompiling the executable with -fstandalone-debug, but it might not play well with the workaround for #​2.

Issue #​1 can be easily worked around, one just needs to pay attention to the current working directory of lldb, no biggie, and gdb may have similar issues, but it's more vocal about them (ie. printing errors during attach). It looks like #​2 needs to be fixed before #​3 can be worked around or resolved, though.

[llvmbot]

Oh, sorry - those flags aren't mutually exclusive. If you have -gsplit-dwarf working (ie: you're not getting the errors about missing .dwo files)

The thing is, I don't: it's only after I removed -gsplit-dwarf that things like "expr this" started to work in lldb.

Let me write a quick summary for anyone having similar problems and stumbling upon this bug as there are a few issues and it's easy to lose track of the specific workarounds:

1) LLDB can attach to chrome, but doesn't show any variables or any source code --- worked around by running lldb from the source root. 2) LLDB can attach to chrome, displays source code and most variables, but throws numerous "adding range" errors, and trivial things like "expr this" fail to work --- worked around by recompiling the executable without -gsplit-dwarf. 3) LLDB can attach to chrome, displays source code and most variables, "expr this" works as expected, but "incomplete definition" errors are displayed when printing a bracktrace and the debugger terminates when trying to do things like "expr this->method" --- can be worked around by recompiling the executable with -fstandalone-debug, but it might not play well with the workaround for #​2.

Issue #​1 can be easily worked around, one just needs to pay attention to the current working directory of lldb, no biggie, and gdb may have similar issues, but it's more vocal about them (ie. printing errors during attach). It looks like #​2 needs to be fixed before #​3 can be worked around or resolved, though.

[tberghammer]

I was the one originally implemented split dwarf support in LLDB. The current status is that we have no active development in that field but I still do some bug fixing and plan to look into this issues as it would be a good test to get chrome debugging working.

About relative path I seen some build system produces paths starting with /proc/self/cwd when they want to generate machine independent path and I remember seeing somebody (I think Oleksiy) adding support for that. Probably we can reuse the same logic to handle the case when a relative path is specified for the compile unit dwo file.

For GDB my guess (haven't checked it) would be that they compare the executable path and the compile unit path and have some heuristics to find the dwo file (e.g. find matching subpaths). We can try to have something similar but I am not sure how much value it would have. Using an LLDB setting for it might be easier and give a more consistent user experience but it will increase the learning curve

[dwblaikie]

You issue with a base class having a forward declaration can be solved by adding "-fstandalone-debug" to your CFLAGS. On non darwin platform "-flimit-debug-info" is the default setting and this can cause base classes and other types to be omitted from the debug info when these types are needed to reconstruct the types. Try adding -fstandalone-debug to your C and C++ flags and try once more. The assumption the compiler is making is that you have access to the debug info for your C++ library that contains std::cxx1998::_Vector_base(), which you very well might. LLDB currently doesn't allow the static notion of a type from one executable (chrome) to load the full definition of a type (std::cxx1998::_Vector_base) from another (somelibc++.so). There is a long explanation of why we do this in LLDB and I won't go into that. By try -fstandalone-debug and see how things go.

Okay, so I tried compiling chrome with "-fstandalone-debug" instead of "-gsplit-dwarf".

Oh, sorry - those flags aren't mutually exclusive. If you have -gsplit-dwarf working (ie: you're not getting the errors about missing .dwo files) but you are getting those "does not have a complete definition" then you can add -fstandalone-debug (in addition to -gsplit-dwarf) to fix them.

Yes, it'll make the .dwo debug info bigger, but since the linker never sees that it shouldn't hurt your link times or create any big .a or executable files.

It'll still take more disk space to store the bigger .dwo files, though.

A regular debug build of chrome takes about 21 GB of disk space. With "-fstandalone-debug", it took 56.8 GB when it failed trying to fold 5.3 GB worth of object files into a similar-sized library:

[6/2056] python "../../build/toolchain/gcc_ar_wrapper.py" --output=obj/third_party/WebKit/Source/core/libremaining.a --ar="ar" rcsD @"obj/third_party/WebKit/Source/core/libremaining.a.rsp" FAILED: obj/third_party/WebKit/Source/core/libremaining.a python "../../build/toolchain/gcc_ar_wrapper.py" --output=obj/third_party/WebKit/Source/core/libremaining.a --ar="ar" rcsD @"obj/third_party/WebKit/Source/core/libremaining.a.rsp" ar: obj/third_party/WebKit/Source/core/libremaining.a: File truncated

Good grief.

[llvmbot]

You issue with a base class having a forward declaration can be solved by adding "-fstandalone-debug" to your CFLAGS. On non darwin platform "-flimit-debug-info" is the default setting and this can cause base classes and other types to be omitted from the debug info when these types are needed to reconstruct the types. Try adding -fstandalone-debug to your C and C++ flags and try once more. The assumption the compiler is making is that you have access to the debug info for your C++ library that contains std::cxx1998::_Vector_base(), which you very well might. LLDB currently doesn't allow the static notion of a type from one executable (chrome) to load the full definition of a type (std::cxx1998::_Vector_base) from another (somelibc++.so). There is a long explanation of why we do this in LLDB and I won't go into that. By try -fstandalone-debug and see how things go.

Okay, so I tried compiling chrome with "-fstandalone-debug" instead of "-gsplit-dwarf".

A regular debug build of chrome takes about 21 GB of disk space. With "-fstandalone-debug", it took 56.8 GB when it failed trying to fold 5.3 GB worth of object files into a similar-sized library:

[6/2056] python "../../build/toolchain/gcc_ar_wrapper.py" --output=obj/third_party/WebKit/Source/core/libremaining.a --ar="ar" rcsD @"obj/third_party/WebKit/Source/core/libremaining.a.rsp" FAILED: obj/third_party/WebKit/Source/core/libremaining.a python "../../build/toolchain/gcc_ar_wrapper.py" --output=obj/third_party/WebKit/Source/core/libremaining.a --ar="ar" rcsD @"obj/third_party/WebKit/Source/core/libremaining.a.rsp" ar: obj/third_party/WebKit/Source/core/libremaining.a: File truncated

Good grief.

[dwblaikie]

I would be interested in seeing what GDB does as I have no clue what would usually work. Compilation directory being relative to the executable would be complete luck in most cases. Many people have source in one location and compile from somewhere in the source tree, but the binary exists elsewhere.

Sure, but also many people compile from somewhere (usually the root) in the build tree - most build systems I've seen do this.

It seems like we should just require DW_AT_comp_dir is absolute, or come up with a way to specify the compilation root.

It looks like Chrome's build went out of its way to deliberately make the root not absolute perhaps for distributed build, portability (so the build tree can be moved easily), or some other reason - and GDB seems to support that model, which is nice.

Seems like a reasonable feature request for LLDB.

[llvmbot]

I would be interested in seeing what GDB does as I have no clue what would usually work. Compilation directory being relative to the executable would be complete luck in most cases. Many people have source in one location and compile from somewhere in the source tree, but the binary exists elsewhere. It seems like we should just require DW_AT_comp_dir is absolute, or come up with a way to specify the compilation root.

[llvmbot]

nod I guess if you keep the name as Default it still doesn't work - but if you put that moved Default directory into a directory calle 'out' anywhere in your filesystem, it'll still work (ie: so long as the suffix of the path where the executable is, matches the relative path in the comp_dir, it still finds the dwo files)?

Yes, just tried both: /home/name/Default/chrome doesn't work, /home/name/out/Default/chrome works.

[dwblaikie]

I'm assuming the executable happens to be in the same relative path (/home/name/src/chromium/src/out/Default)?

Yes, this is correct.

I wonder if GDB can still find the right debug info if you move the executable so it's not in that directory path?

The executable depends on certain files from the /Default/ directory, so it won't run at all if moved individually. I copied the entire /Default/ directory elsewhere and renamed it, gdb doesn't like it:

warning: Could not find DWO CU obj/third_party/libwebp/libwebp_utils/quant_levels.dwo(0xaf868fc0950c4165) referenced by CU at offset 0x11e7d59 [in module /home/name/test-directory/chrome]

even though obj/third_party/libwebp/libwebp_utils/quant_levels.dwo can be found relative to the location of the executable.

nod I guess if you keep the name as Default it still doesn't work - but if you put that moved Default directory into a directory calle 'out' anywhere in your filesystem, it'll still work (ie: so long as the suffix of the path where the executable is, matches the relative path in the comp_dir, it still finds the dwo files)?

You could probably ask someone who works on GDB what the search path logic is there & we could see whether it's reasonable to implement that in LLDB.

I don't know anyone from the GDB team, I'm not affiliated with Google or the GNU Project.

Sure sure - not sure who's implementing the split-dwarf support in LLDB at the moment/whether it's actively being improved (I think it was some Google folks working on Android - but I don't follow LLDB development so not sure what status they're at nor who to CC on this bug to see if this is something they're interested in picking up).

But whoever picks it up could probably at least implement the behavior we've observed so far, or go the extra step to check what the broad set of search paths/algorithms is that GDB uses in this regard.

[llvmbot]

I'm assuming the executable happens to be in the same relative path (/home/name/src/chromium/src/out/Default)?

Yes, this is correct.

I wonder if GDB can still find the right debug info if you move the executable so it's not in that directory path?

The executable depends on certain files from the /Default/ directory, so it won't run at all if moved individually. I copied the entire /Default/ directory elsewhere and renamed it, gdb doesn't like it:

warning: Could not find DWO CU obj/third_party/libwebp/libwebp_utils/quant_levels.dwo(0xaf868fc0950c4165) referenced by CU at offset 0x11e7d59 [in module /home/name/test-directory/chrome]

even though obj/third_party/libwebp/libwebp_utils/quant_levels.dwo can be found relative to the location of the executable.

You could probably ask someone who works on GDB what the search path logic is there & we could see whether it's reasonable to implement that in LLDB.

I don't know anyone from the GDB team, I'm not affiliated with Google or the GNU Project.

[llvmbot]

It might be worth adding some sort of DEBUG_WITH_LLDB flag or make setting to the chrome build system so that the build system can do the right thing. This would currently disable the -gsplit-dwarf until we can get LLDB fixed (or fix the compiler), and add the "-fstandalone-debug" to the C and C++ flags.

That'd be useful indeed, although I get this eerie feeling that I'm the first person in the world to ever try debugging chrome in lldb ;-)

I'll try recompiling with "-fstandalone-debug" in a few hours and see how it goes. Thanks!

[dwblaikie]

Plus "-gsplit-dwarf" as it was disabled in the build this log is from. "-fdebug-prefix-map=/home/name/src/chromium/src=." seems suspicious to my untrained eye.

Yep. That would do it.

Now the question is how does GCC know to resolve relative paths correctly.

I'm assuming the executable happens to be in the same relative path (/home/name/src/chromium/src/out/Default)? I wonder if GDB can still find the right debug info if you move the executable so it's not in that directory path?

You could probably ask someone who works on GDB what the search path logic is there & we could see whether it's reasonable to implement that in LLDB.

[llvmbot]

It might be worth adding some sort of DEBUG_WITH_LLDB flag or make setting to the chrome build system so that the build system can do the right thing. This would currently disable the -gsplit-dwarf until we can get LLDB fixed (or fix the compiler), and add the "-fstandalone-debug" to the C and C++ flags.

[llvmbot]

You issue with a base class having a forward declaration can be solved by adding "-fstandalone-debug" to your CFLAGS. On non darwin platform "-flimit-debug-info" is the default setting and this can cause base classes and other types to be omitted from the debug info when these types are needed to reconstruct the types. Try adding -fstandalone-debug to your C and C++ flags and try once more. The assumption the compiler is making is that you have access to the debug info for your C++ library that contains std::cxx1998::_Vector_base(), which you very well might. LLDB currently doesn't allow the static notion of a type from one executable (chrome) to load the full definition of a type (std::cxx1998::_Vector_base) from another (somelibc++.so). There is a long explanation of why we do this in LLDB and I won't go into that. By try -fstandalone-debug and see how things go.

[llvmbot]

Getting a precise command line for one of the object files would be useful, as Clang doesn't produce a relative comp_dir in simple examples I tried.

Like this?:

[19609/24679] ../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF obj/third_party/WebKit/Source/core/html/HTMLTitleElement.o.d -DV8_DEPRECATION_WARNINGS -DENABLE_MDNS=1 -DENABLE_NOTIFICATIONS -DENABLE_PEPPER_CDMS -DENABLE_PLUGINS=1 -DENABLE_PDF=1 -DENABLE_PRINTING=1 -DENABLE_BASIC_PRINTING=1 -DENABLE_PRINT_PREVIEW=1 -DENABLE_SPELLCHECK=1 -DUSE_UDEV -DUI_COMPOSITOR_IMAGE_TRANSPORT -DUSE_AURA=1 -DUSE_PANGO=1 -DUSE_CAIRO=1 -DUSE_CLIPBOARD_AURAX11=1 -DUSE_DEFAULT_RENDER_THEME=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DENABLE_WEBRTC=1 -DENABLE_EXTENSIONS=1 -DENABLE_TASK_MANAGER=1 -DENABLE_THEMES=1 -DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DENABLE_SESSION_SERVICE=1 -DENABLE_SUPERVISED_USERS=1 -DENABLE_SERVICE_DISCOVERY=1 -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD -DENABLE_MEDIA_ROUTER=1 -DFIELDTRIAL_TESTING_ENABLED -DCR_CLANG_REVISION=274369-1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DSTDC_CONSTANT_MACROS -DSTDC_FORMAT_MACROS -D_DEBUG -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DWTF_USE_DYNAMIC_ANNOTATIONS=1 -D_GLIBCXX_DEBUG=1 -DBLINK_CORE_IMPLEMENTATION=1 -DGL_GLEXT_PROTOTYPES -DUSE_GLX -DUSE_EGL -DBLINK_IMPLEMENTATION=1 -DINSIDE_BLINK -DSK_IGNORE_DW_GRAY_FIX -DSK_IGNORE_LINEONLY_AA_CONVEX_PATH_OPTS -DSK_SUPPORT_GPU=1 -DENABLE_LAYOUT_UNIT_IN_INLINE_BOXES=0 -DENABLE_OILPAN=1 -DWTF_USE_DYNAMIC_ANNOTATIONS=1 -DWTF_USE_CONCATENATED_IMPULSE_RESPONSES=1 -DWTF_USE_ICCJPEG=1 -DWTF_USE_QCMSLIB=1 -DWTF_USE_WEBAUDIO_FFMPEG=1 -DWTF_USE_DEFAULT_RENDER_THEME=1 -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DU_NOEXCEPT= -DU_STATIC_IMPLEMENTATION -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE -DLIBXSLT_STATIC -I../.. -Igen -I../../third_party/khronos -I../../gpu -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I../../third_party/libwebp -I../../third_party/WebKit/Source -Igen/blink -I../../third_party/WebKit/Source -I../../third_party/WebKit -Igen/blink -Igen/third_party/WebKit -I../../skia/config -I../../skia/ext -I../../third_party/skia/include/c -I../../third_party/skia/include/config -I../../third_party/skia/include/core -I../../third_party/skia/include/effects -I../../third_party/skia/include/images -I../../third_party/skia/include/lazy -I../../third_party/skia/include/pathops -I../../third_party/skia/include/pdf -I../../third_party/skia/include/pipe -I../../third_party/skia/include/ports -I../../third_party/skia/include/utils -I../../third_party/skia/include/gpu -I../../third_party/skia/src/gpu -I../../third_party/icu/source/common -I../../third_party/icu/source/i18n -I../../third_party/angle/include -I../../third_party/angle/src/common/third_party/numerics -Igen/angle -I../../third_party/iccjpeg -I../../third_party/libpng -I../../third_party/zlib -I../../third_party/libxml/src/include -I../../third_party/libxml/linux/include -I../../third_party/libxslt -I../../third_party/ots/include -I../../third_party/qcms/src -I../../third_party/snappy/src -I../../third_party/snappy/linux -I../../v8/include -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -funwind-tables -fPIC -pipe -B../../third_party/binutils/Linux_x64/Release/bin -fcolor-diagnostics -fdebug-prefix-map=/home/name/src/chromium/src=. -pthread -m64 -march=x86-64 -Wall -Werror -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-covered-switch-default -Wno-deprecated-register -Wno-unneeded-internal-declaration -Wno-inconsistent-missing-override -Wno-shift-negative-value -Wno-undefined-var-template -Wno-nonportable-include-path -O0 -g2 -fvisibility=hidden -Xclang -load -Xclang ../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.so -Xclang -add-plugin -Xclang find-bad-constructs -Xclang -plugin-arg-find-bad-constructs -Xclang check-templates -Xclang -plugin-arg-find-bad-constructs -Xclang follow-macro-expansion -Xclang -plugin-arg-find-bad-constructs -Xclang check-implicit-copy-ctors -Xclang -plugin-arg-find-bad-constructs -Xclang check-ipc -Wheader-hygiene -Wstring-conversion -Wexit-time-destructors -Wglobal-constructors -Xclang -load -Xclang ../../third_party/llvm-build/Release+Asserts/lib/libBlinkGCPlugin.so -Xclang -add-plugin -Xclang blink-gc-plugin -DLIBXML_STATIC= -fno-threadsafe-statics -fvisibility-inlines-hidden -Wno-undefined-bool-conversion -Wno-tautological-undefined-compare -std=gnu++11 -fno-rtti -fno-exceptions -c ../../third_party/WebKit/Source/core/html/HTMLTitleElement.cpp -o obj/third_party/WebKit/Source/core/html/HTMLTitleElement.o

Plus "-gsplit-dwarf" as it was disabled in the build this log is from. "-fdebug-prefix-map=/home/name/src/chromium/src=." seems suspicious to my untrained eye.

[dwblaikie]

I recompiled without -gsplit-dwarf (took a few hours). Yes, the address ranges warnings are gone, and I can even print "this" now. It does look like the primary problem is DWO related indeed, although there might be a few more unrelated issues:

(lldb) bt error: chrome :: Class '_Vector_impl' has a base class 'std::__cxx1998::_Vector_base<char, std::allocator >::_Tp_alloc_type' which does not have a complete definition. error: chrome :: Try compiling the source file with -fno-limit-debug-info.

As per the error message here, LLDB doesn't support some of the output size optimizations implemented in Clang. You can disable these optimizations by passing Clang the "-fstandalone-debug" (or the old name as mentioned in the diagnostic "-fno-limit-debug-info").

(platforms where LLDB is the system/default/common debugger default these options in that direction)

[llvmbot]

I recompiled without -gsplit-dwarf (took a few hours). Yes, the address ranges warnings are gone, and I can even print "this" now. It does look like the primary problem is DWO related indeed, although there might be a few more unrelated issues:

(lldb) bt error: chrome :: Class '_Vector_impl' has a base class 'std::__cxx1998::_Vector_base<char, std::allocator >::_Tp_alloc_type' which does not have a complete definition. error: chrome :: Try compiling the source file with -fno-limit-debug-info.

• thread #​1: tid = 29176, 0x0000563a1ed63f8b chrome`blink::Document::setDesignMode(this=0x00002e1e907a24e0, value=0x00007ffcd8dfc100) + 27 at Document.cpp:4634, name = 'chrome', stop reason = breakpoint 1.1 (...) (lldb) expr this (blink::HTMLDocument *) $1 = 0x00000673eaec24e0 (lldb) expr this->url Aborted (core dumped) name@name:~/src/chromium/src$

[dwblaikie]

Getting a precise command line for one of the object files would be useful, as Clang doesn't produce a relative comp_dir in simple examples I tried.

That said, GDB seems to be able to work with these relative dirs & it'd be useful to understand how it does so - perhaps it uses the executabel path as another search directory to resolve the relative path?

(&, yes, testing without split-dwarf would also be useful just to make sure we're isolating the right subset of issues)

[llvmbot]

I CC'ed some extra DWARF experts to so they are in the loop.

[llvmbot]

If you can disable -gsplit-dwarf you should be able to debug just fine. It would be nice to try this out and make sure that you don't see any of the warnings about the address ranges being incorrect. This will help us know that the problem is DWO related.

[llvmbot]

Sounds like a DWO bug as I can see from the DWARF that DWO files are being used:

<0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_stmt_list : 0x0 <10> DW_AT_GNU_dwo_name: (indirect string, offset: 0x0): obj/chrome/chrome_initial/chrome_exe_main_aura.dwo <14> DW_AT_comp_dir : (indirect string, offset: 0x33): ./out/Default <18> DW_AT_GNU_dwo_id : 0x2e0b001d737b2f0a <20> DW_AT_GNU_addr_base: 0x0 <24> DW_AT_low_pc : 0xd9e7a0 <2c> DW_AT_high_pc : 0x28 The troubling thing here is that the DW_AT_comp_dir has a relative path or "./out/Default". This seems like a compiler bug as when any paths in a DWARF DIE, like the value of DW_AT_GNU_dwo_name which is "obj/chrome/chrome_initial/chrome_exe_main_aura.dwo", are relative, the paths are resolved using the DW_AT_comp_dir value, but that is a relative path as well. As for the image lookup -va `$pc` failing, just grab the actual PC value from your current stack frame and insert it in place of the `$pc`. Backticks evaluate an expression ("$pc") and insert the scalar result in its place, kind of like a preprocessor inserts text for a #define. So it sounds like we need to file a bug against the compiler to ensure that when -gsplit-dwarf is used, the DW_AT_comp_dir shouldn't be relative. This is why you currently need to run the debugger from the directory that things were compiled in, but this is definitely something the compiler should fix unless the debugger is supposed to deduce the relative base in some other way that I don't know about.

[llvmbot]

Sorry for a little delay here. Here's the output:

---

(lldb) image lookup -va $pc error: error: use of undeclared identifier '$lldb_local_vars' error: use of undeclared identifier '$lldb_local_vars' (lldb)

It also displays additional "adding range" errors on the first attempt, but not subsequent ones. I guess that "adding range" errors are produced when the debug info is being read, and they're gone once it's all cached in memory.

name@name:~$ objdump -g /path/to/chrome | grep -A50 "Contents of the .debug_info section" Contents of the .debug_info section:

Compilation Unit @ offset 0x0: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x0 Pointer Size: 8

<0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_stmt_list : 0x0 <10> DW_AT_GNU_dwo_name: (indirect string, offset: 0x0): obj/chrome/chrome_initial/chrome_exe_main_aura.dwo <14> DW_AT_comp_dir : (indirect string, offset: 0x33): ./out/Default <18> DW_AT_GNU_dwo_id : 0x2e0b001d737b2f0a <20> DW_AT_GNU_addr_base: 0x0 <24> DW_AT_low_pc : 0xd9e7a0 <2c> DW_AT_high_pc : 0x28 Compilation Unit @ offset 0x30: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x17 Pointer Size: 8 <0><3b>: Abbrev Number: 1 (DW_TAG_compile_unit) <3c> DW_AT_stmt_list : 0x6b <40> DW_AT_GNU_dwo_name: (indirect string, offset: 0x41): obj/chrome/chrome_initial/chrome_main.dwo <44> DW_AT_comp_dir : (indirect string, offset: 0x33): ./out/Default <48> DW_AT_GNU_dwo_id : 0x3f4a2b77c070c272 <50> DW_AT_GNU_addr_base: 0x8 <54> DW_AT_low_pc : 0x0 <5c> DW_AT_ranges : 0x0 Compilation Unit @ offset 0x60: Length: 0xaa (32-bit) Version: 4 Abbrev Offset: 0x2e Pointer Size: 8 <0><6b>: Abbrev Number: 1 (DW_TAG_compile_unit) <6c> DW_AT_stmt_list : 0x46b <70> DW_AT_GNU_dwo_name: (indirect string, offset: 0x6b): obj/chrome/chrome_initial/chrome_main_delegate.dwo <74> DW_AT_comp_dir : (indirect string, offset: 0x33): ./out/Default <78> DW_AT_GNU_dwo_id : 0x92aae6f3a580b5dd <80> DW_AT_GNU_addr_base: 0x18 <84> DW_AT_GNU_ranges_base: 0x30 <88> DW_AT_low_pc : 0x0 <90> DW_AT_ranges : 0x210 <1><94>: Abbrev Number: 2 (DW_TAG_subprogram) <95> DW_AT_name : (indirect string, offset: 0x9e): load <1><99>: Abbrev Number: 3 (DW_TAG_subprogram) <9a> DW_AT_low_pc : 0xda21b0 DW_AT_high_pc : 0xf3 DW_AT_name : (indirect string, offset: 0xa9): Acquire_Load <2>: Abbrev Number: 4 (DW_TAG_inlined_subroutine) DW_AT_abstract_origin: <0x94> DW_AT_low_pc : 0xda21d4 name@name:~$ ---- I'm not too familiar with the chrome build environment, but I'll have a look. It looks that "-gsplit-dwarf" is added conditionally in /build/config/compiler/BUILD.gn

[llvmbot]

Can you check if "-gsplit-dwarf" is being passed to the compiler when compiling your source files? If so, maybe you can take that out and rebuild to see if that helps debugging? The link stage will take longer since it will need to link the debug info, but debugging might improve. This will help tell us if this is the DWO support that isn't working or if we have some other issue.

[llvmbot]

One difference between gdb and LLDB is we actually show extra stack frames for inlined functions. Maybe GDB has been changed to show inline stack frames, but last I knew it displayed all of the variables for the all inlined functions and the concrete functions. I am not sure if that is what is going on here.

When you are stopped at Document.cpp:4634 what does the following show:

(lldb) image lookup -va $pc

As for the messages:

error: chrome 0xc8364500004eae: adding range [0xd9ffd5-0xda000b) which has a base that is less than the function's low PC 0x4f0acb0. Please file a bug and attach the file at the start of this error message

This is saying you have debug info that has a function that is says has an address range of [0x1000-0x2000) and it has a child block of [0x3000-3100). That doesn't make sense and it is a bug in the debug info generated by the compiler. It DWARF debug info, any DW_TAG_subprogram (a function) will have child DW_TAG_lexical_block or DW_TAG_inlined_subroutine that have address ranges that must be contained within the parent.

This might also be a bug in the DWO implmentation. DWO is a way of having DWARF debug info be emitted in a separate file for each compile unit. The main executable then has just a skeleton DWARF that points to the real DWARF in the .dwo files. Having to run LLDB from the root directory would then make sense if the DWO support in LLDB is not able to handle relative paths. This would cause variables and source to go missing. So I am going to guess that we have incomplete DWO support.

What does the output of the following command show?:

% objdump -g | grep -A50 "Contents of the .debug_info section"

(replace with the path to the binary where you were setting a breakpoint in).

[tberghammer]

These are pretty similar to what I am seeing (I seen some other ones as well).

For displaying local variables you can try to use "frame variable this" (or "fr va this") and that should work much better. Using "expr" try to do an expression evaluation what is much more fragile especially in large applications.

For bug reports I think a single meta bug for now is enough as we don't have too much details for it and I plan to open separate ones when I have more understanding about what is going wrong.

[llvmbot]

Thank you for looking into this! Yes, running lldb from the source directory did the trick, at least for the missing source and variables problem. It appears that gdb is somehow able to deduce the source location without looking at the current working directory, and I took it for granted that lldb would do the same.

Yup, there are more problems, here's what I've noticed on my end:

1. There are tons of SIGSTOPs that I had to silence with "process handle SIGSTOP --stop false --notify false".

2. "bt" throws the following errors before showing the stacktrace: (lldb) bt error: chrome 0xc8364500004eae: adding range [0xd9ffd5-0xda000b) which has a base that is less than the function's low PC 0x4f0acb0. Please file a bug and attach the file at the start of this error message error: chrome 0xc8364500004eae: adding range [0xda0024-0xda0063) which has a base that is less than the function's low PC 0x4f0acb0. Please file a bug and attach the file at the start of this error message error: chrome 0xc836dd0000b528: adding range [0xd9e7d0-0xd9e82d) which has a base that is less than the function's low PC 0x4f0c410. Please file a bug and attach the file at the start of this error message error: chrome 0xc836dd0000b528: adding range [0xd9e830-0xd9e860) which has a base that is less than the function's low PC 0x4f0c410. Please file a bug and attach the file at the start of this error message

3. When trying to display "this" after a breakpoint is hit in blink::Document::setDesignMode:

gdb: Breakpoint 1, blink::Document::setDesignMode (this=0x243dfc0e24e0, value=...) at ../../third_party/WebKit/Source/core/dom/Document.cpp:4634 4634 bool newValue = m_designMode; (gdb) p this $1 = (blink::Document *) 0x243dfc0e24e0

lldb: (lldb) f frame #​0: 0x0000563478ccaf8b chrome`blink::Document::setDesignMode(this=0x00001115694624e0, value=0x00007ffecbb8f6b0) + 27 at Document.cpp:4634 4631 4632 void Document::setDesignMode(const String& value) 4633 { -> 4634 bool newValue = m_designMode; 4635 if (equalIgnoringCase(value, "on")) { 4636 newValue = true; 4637 UseCounter::count(*this, UseCounter::DocumentDesignModeEnabeld); (lldb) expr this error: chrome 0xefc0470002fb67: adding range [0xd9e830-0xd9e860) which has a base that is less than the function's low PC 0xa435510. Please file a bug and attach the file at the start of this error message (... tons of similar errors ...) warning: (x86_64) /(...)/out/Default/chrome 0xf1a91300161f42: DW_AT_specification(0x000025be) has no decl

error: use of undeclared identifier '$lldb_local_vars' error: use of undeclared identifier '$lldb_local_vars' error: invalid use of 'this' outside of a non-static member function (lldb)

4. The problem with detach mentioned in the original post persists - a detached Chrome renderer process is completely unresponsive, and lldb can't connect to anything else ("error: no error returned from Target::Attach, and target has no process"). I'm not sure what happens here, it's as though detach failed silently?

Are these the problems you're seeing? I can open separate bugs for any of those if needed. #​3 is particularly critical as it makes debugging impossible in some cases.

I'm running chrome using the following command line: ./chrome --disable-gpu --allow-sandbox-debugging --disable-hang-monitor http://127.0.0.1 And then attaching to the renderer process.

[tberghammer]

I tried to debug chrome with ToT LLDB and even though I hit a lot of problem (I am planning to look into them) it wasn't as bad as you mentioned. I was able to see the source code and most local variables. Can you gave some instructions about how can I reproduce the problem you see (I have chrome checked out based on http://dev.chromium.org/developers/how-tos/get-the-code).

One important thing I noticed is that LLDB will only work if the current working directory of LLDB is the same as the source base directory (where you have build.ninja, out/Default, etc...) because the compiled binaries are only containing relative paths to the debug info and source code. You can see that it tries (and fails) to load "./out/Default/../../third_party/WebKit/Source/core/dom/Document.cpp" what is a relative path to your current working directory.