[lldb-dev] [5.0.0 Release] Only 3 release blockers left, please help fix!
Hello everyone, We started the week with 32 open release blockers and are now down to only 3: https://bugs.llvm.org/buglist.cgi?f1=blocked&o1=equals&v1=33849&query_format=advanced&resolution=--- Many thanks for your hard work so far. None of the three remaining ones have any traction, so any help would be much appreciated: https://llvm.org/pr33668 "Excessive memory and CPU use in tail duplication and associated passes due to critical edge splitting" Sounds like someone familiar with taildup is needed. https://llvm.org/pr33930 "Assertion `OpN.isUniqued() && "Only uniqued operands cannot be mapped immediately"' failed." Needs someone familiar with debug info. https://llvm.org/pr33507 "Assertion failed: Shift >= 0, file C:\src\llvm_package_303050\llvm\tools\clang\lib\Format\WhitespaceManager.cpp, line 245" clang-format asserts and breaks the correctness of some code. This seems bad. Needs someone familiar with clang-format. If we can get these squashed, I'll be a very happy release manger. Thanks, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [5.0.0 Release] Release Candidate 1 tagged
On Tue, Aug 1, 2017 at 3:01 AM, Simon Dardis wrote: > Hi all, > > I have new regressions for mips(el)-linux-gnu, some of which I have patches > for: > > I have patch for (believe this to be a libc bug): > LLVM-Unit :: > DebugInfo/DWARF/./DebugInfoDWARFTests/DWARFDebugInfo.TestDwarfVerifyInvalidCURef > LLVM-Unit :: > DebugInfo/DWARF/./DebugInfoDWARFTests/DWARFDebugInfo.TestDwarfVerifyInvalidLineFileIndex > LLVM-Unit :: > DebugInfo/DWARF/./DebugInfoDWARFTests/DWARFDebugInfo.TestDwarfVerifyInvalidLineSequence > LLVM-Unit :: > DebugInfo/DWARF/./DebugInfoDWARFTests/DWARFDebugInfo.TestDwarfVerifyInvalidStmtList > This appears to be a known regression (PR32910): > Builtins-mips64-linux :: divtc3_test.c > New, investigating: > Clang :: Index/IBOutletCollection.m > Clang :: Index/TestClassDecl.m > Clang :: Index/TestClassForwardDecl.m > Clang :: Index/allow-editor-placeholders.cpp > Clang :: Index/annotate-attribute.cpp > Clang :: Index/annotate-comments-availability-attrs.cpp > Clang :: Index/annotate-comments-objc.m > Clang :: Index/annotate-comments-property-accessor.m > Clang :: Index/annotate-comments-typedef.m > Clang :: Index/annotate-comments-unterminated.c > Clang :: Index/annotate-comments.cpp > Clang :: Index/annotate-context-sensitive.cpp > Clang :: Index/annotate-deep-statements.cpp > Clang :: Index/annotate-literals.m > Clang :: Index/annotate-macro-args.m > Clang :: Index/annotate-module.m > Clang :: Index/annotate-nested-name-specifier.cpp > Clang :: Index/annotate-parameterized-classes.m > Clang :: Index/annotate-subscripting.m > Clang :: Index/annotate-tokens-cxx0x.cpp > Clang :: Index/annotate-tokens-include.c > Clang :: Index/annotate-tokens-pp.c > Clang :: Index/annotate-tokens-preamble.c > Clang :: Index/annotate-tokens-with-default-args.cpp > Clang :: Index/annotate-tokens.c > Clang :: Index/annotate-tokens.cpp > Clang :: Index/annotate-tokens.m > Clang :: Index/annotate-toplevel-in-objccontainer.m > Clang :: Index/arc-annotate.m > Clang :: Index/asm-attribute.c > Clang :: Index/attributes-cuda.cu > Clang :: Index/attributes.c > Clang :: Index/availability.c > Clang :: Index/availability.cpp > Clang :: Index/blocks.c > Clang :: Index/boxed-exprs.m > Clang :: Index/c-index-api-loadTU-test.m > Clang :: Index/c-index-getCursor-pp.c > Clang :: Index/c-index-getCursor-test.m > Clang :: Index/c-index-pch.c > Clang :: Index/c-index-redecls.c > Clang :: Index/cindex-from-source.m > Clang :: Index/cindex-on-invalid.m > Clang :: Index/comment-c-decls.c > Clang :: Index/comment-cplus-decls.cpp > Clang :: Index/comment-cplus-template-decls.cpp > Clang :: Index/comment-cplus11-specific.cpp > Clang :: Index/comment-custom-block-command.cpp > Clang :: Index/comment-lots-of-unknown-commands.c > Clang :: Index/comment-misc-tags.m > Clang :: Index/comment-objc-decls.m > Clang :: Index/comment-objc-parameterized-classes.m > Clang :: Index/comment-to-html-xml-conversion.cpp > Clang :: Index/comment-unqualified-objc-pointer.m > Clang :: Index/comment-with-preamble.c > Clang :: Index/complete-module-undef.m > Clang :: Index/crash-recovery-modules.m > Clang :: Index/ctor-init-source-loc.cpp > Clang :: Index/cursor-ref-names.cpp > Clang :: Index/cxx11-lambdas.cpp > Clang :: Index/evaluate-cursor.cpp > Clang :: Index/file-includes.c > Clang :: Index/file-macro-refs.c > Clang :: Index/file-refs-subscripting.m > Clang :: Index/file-refs.c > Clang :: Index/file-refs.cpp > Clang :: Index/file-refs.m > Clang :: Index/fix-its.c > Clang :: Index/fix-its.m > Clang :: Index/format-comment-cdecls.c > Clang :: Index/get-cursor-includes.c > Clang :: Index/get-cursor.c > Clang :: Index/get-cursor.cpp > Clang :: Index/get-cursor.m > Clang :: Index/getcursor-pp-pch.c > Clang :: Index/getcursor-preamble.m > Clang :: Index/headerfile-comment-to-html.m > Clang :: Index/in-class-init.cpp > Clang :: Index/index-attrs.c > Clang :: Index/index-attrs.cpp > Clang :: Index/index-attrs.m > Clang :: Index/index-decls.m > Clang :: Index/index-file.cpp > Clang :: Index/index-file.cu > Clang :: Index/index-invalid-code.m > Clang :: Index/index-kernel-invocation.cpp > Clang :: Index/index-many-call-ops.cpp > Clang :: Index/index-many-logical-ops.c > Clang :: Index/index-module-with-vfs.m > Clang :: Index/index-module.m > Clang :: Index/index-pch-objc.m > Clang :: Index/index-pch-with-module.m > Clang :: Index/index-pch.cpp > Clang :: Index/index-refs.cpp > Clang :: Index/index-refs.m > Clang :: Index/index-subscripting-literals.m > Clang :: Index/index-suppress-refs.cpp > Clang :: Index/index-suppress-refs.m > Clang :: Index/index-te
Re: [lldb-dev] [Release-testers] [5.0.0 Release] Release Candidate 2 tagged
On Mon, Aug 14, 2017 at 3:36 AM, Dimitry Andric wrote: > On 11 Aug 2017, at 04:00, Hans Wennborg via Release-testers > wrote: >> 5.0.0-rc2 was just tagged. >> >> I know we still have a bunch of open release blockers, but there has >> been a lot of merged patches and I'd like to find out what the status >> is. > > As in the last rc, most of the ASan tests failed with either: > > [ DEATH ] ==5754==AddressSanitizer CHECK failed: > /home/dim/llvm-5.0.0/rc2/llvm.src/projects/compiler-rt/lib/asan/asan_errors.h:99 > "((second_free_stack->size)) > ((0))" (0x0, 0x0) > > or: > > [ DEATH ] ==7514==AddressSanitizer CHECK failed: > /home/dim/llvm-5.0.0/rc2/llvm.src/projects/compiler-rt/lib/asan/asan_descriptions.cc:176 > "((id)) != (0)" (0x0, 0x0) > > This is likely due to r305058, as mentioned in my report for rc1. Was there ever any progress on this, or at least a bug report filed? Do you think it's just the tests that are failing, or does it mean ASan is broken on FreeBSD? How severe is this issue from your perspective? Thanks, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Difficulty in using target.source-map to map source files
> On Aug 24, 2017, at 10:06 AM, karnajit wangkhem wrote:
>
> Hi Jim,
>
> Thanks for the valuable reply. Please find my comments inline.
>
> Regards,
> Karan
>
> On Wed, Aug 23, 2017 at 12:32 AM, Jim Ingham wrote:
>
> > On Aug 21, 2017, at 12:02 PM, karnajit wangkhem via lldb-dev
> > wrote:
> >
> > Hi All,
> >
> > Below is a sample example, where target.source-map seems to have a
> > limitation. The limitation seems to be because
> > 1. lldb does not have an equivalent command like directory in gdb
>
> The gdb "dir" command seemed always to be more annoying than useful in real
> situations. If your project had any complexity in the directory structure
> you ended up having to add dir commands for all the subdirectories, which got
> tedious quickly. Since you pretty much always move your sources around
> rigidly, "source maps" are a more natural way to specify this.
>
> Note, we could add a recursive "dir" command, but you can't do the
> simpleminded recursive search or you'll mess up when the sources have same
> named files in different directories. Because of this, again the source maps
> seem more suited.
>
>
> -- Really a good info to know. Thanks!
>
> > 2. target.source-map does not accept multiple mapping entries. I checked
> > this only with freebsd.
> >
> > (lldb) settings show target.source-map
> > target.source-map (path-map) =
> > [0] "/home/karnajitw/lldb_test_execs/test_source_line1" ->
> > "/u/test/test_source_line1"
>
> That is not correct:
>
> (lldb) settings set target.source-map /some/source/path /tmp
> /some/other/source/path /tmp
> (lldb) settings show target.source-map
> target.source-map (path-map) =
> [0] "/some/source/path" -> "/tmp"
> [1] "/some/other/source/path" -> "/tmp"
>
> or
>
> (lldb) set set target.source-map /some/source/path /tmp
> (lldb) set append target.source-map /some/other/source/path /tmp
> (lldb) set show target.source-map
> target.source-map (path-map) =
> [0] "/some/source/path" -> "/tmp"
> [1] "/some/other/source/path" -> "/tmp"
>
> - Thanks! This helped.
>
> >
> > 3. Haven't checked in the code yet, but if we see the mappings of scenario
> > 1, they all point to a single real path
> > /home/karnajitw/lldb_test_execs/test_source_line1. But looks like the
> > mapping logic only considers strings into account. But, at the same time, I
> > am not claiming that they should be interpreted as path from a different
> > machine during the mapping.
> >
>
> I'm not sure what you mean here. lldb does what it can to unwind the source
> path, but it doesn't assume that those paths actually exist locally, so the
> most it can do is remove redundant "/"-s and "/./"-s and unwind ".."-s. We
> do this before most source path comparisons (it's part of the FileSpec Equals
> method). We've been tinkering with this over time so make sure you are using
> a recent version of lldb. If there are places where we don't do this, then
> that's easily fixed.
>
>
> - Your answer is in line with what I wanted to know. My lldb should be quite
> recent. But I used it only for freebsd currently.
>
> % ./lldb --version
> lldb version 5.0.0 (http://llvm.org/svn/llvm-project/lldb/trunk revision
> 305778)
> clang revision 305546
> llvm revision 305548
>
>
> > I want to check on this issue in-depth. But before that, want to confirm if
> > this is real issue or there are other ways to deal these scenarios which I
> > am not aware of?
> >
> > I am referring below link for the lldb commands.
> > https://lldb.llvm.org/lldb-gdb.html
> >
> > 1. First scenario: Different souce file path representation
> >
> > [/home/karnajitw/lldb_test_execs/test_source_line1] $ clang -O0 -g
> > /home/karnajitw/lldb_test_execs///test_source_line1/main.c
> > /home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1/a/ainc.c
> > /home/karnajitw/lldb_test_execs/test_source_line1/a/b/binc.c
> >
> > Machine 1: /home/karnajitw/lldb_test_execs/test_source_line1 -> Machine 2:
> > /u/test/test_source_line1
> >
> > test_source_line1
> > |-- a
> > | |-- ainc.c
> > | |-- ainc.h
> > | `-- b
> > | |-- binc.c
> > | `-- binc.h
> > |-- a.out
> > `-- main.c
> >
> > % ./lldb test_source_line1/a.out
> >
> > (lldb) target create "test_source_line1/a.out"
> > Current executable set to 'test_source_line1/a.out' (x86_64).
> > (lldb) l main
> > File: /home/karnajitw/lldb_test_execs///test_source_line1/main.c
> > (lldb) l afn
> > File:
> > /home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1/a/ainc.c
> > (lldb) l bfn
> > File: /home/karnajitw/lldb_test_execs/test_source_line1/a/b/binc.c
> >
> > (lldb) settings set target.source-map
> > /home/karnajitw/lldb_test_execs///test_source_line1
> > /u/test/test_source_line1
> >
> > (lldb) l main
> > File: /home/karnajitw/lldb_test_execs///test_source_line1/main.c
> >1#include "a/ainc.h"
> >2
> >3int main()
> >4{
> >5 afn();
> >6
> >7 bfn();
> >
Re: [lldb-dev] RFC for DWZ = DW_TAG_imported_unit + DWARF-5 supplementary files
> On Aug 24, 2017, at 8:38 AM, Jan Kratochvil wrote: > > On Wed, 23 Aug 2017 23:55:00 +0200, Greg Clayton wrote: >>> On Aug 23, 2017, at 2:06 PM, Jan Kratochvil via lldb-dev >>> wrote: >>> Currently it always has to as on non-OSX platforms it is using >>> DWARFCompileUnit::Index(). But as I plan to implement DWARF-5 .debug_names >>> index (like __apple_* index) maybe LLDB then no longer needs to populate >>> m_die_array and so just expanding all DW_TAG_partial_unit into a single >>> m_die_array for each DW_TAG_compile_unit is fine? >> >> So I glossed over the documentation and I gathered that DWARF type info >> might be stored in other DWARF files and references from the current file. > > Yes. Arbitrary DIEs, not just type-defining DIEs. DW_TAG_imported_unit can > happen anywhere according to the DWARF standard but for the DWZ/Fedora case it > is a bit simpler one can limit the support for only DW_TAG_imported_unit with > parent of DW_TAG_compile_unit (or DW_TAG_partial_unit for nested imports). > DWZ ever uses DW_TAG_imported_unit only at the CU/PU top level. > > >> SymbolFileDWARFDebugMap is an example of how we do things on MacOS. We have >> one clang::ASTContext in the SymbolFileDWARFDebugMap, and multiple external >> .o files (where each ins a SymbolFileDWARF instance) that contain unlinked >> DWARF. Each SymbolFileDWARF instance will have: >> >> void SymbolFileDWARF::SetDebugMapModule(const lldb::ModuleSP &module_sp); >> >> called to indicate it is actually part of the SymbolFileDWARFDebugMap. >> Then there are functions that check the debug map file and return the >> UniqueDWARFASTTypeMap or the TypeSystem from the SymbolFileDWARFDebugMap if >> we have one: > > Therefore IIUC you make a single context for all types from a compiled > program? Primitive (non-class) types can be different across CUs: > CU1: typedef int foo_t; > CU2: typedef long foo_t; We can and we do allow this. We will have two foo_t definitions in the AST context at the same level. Each variable has the correct type as it directly points to the right "foo_t". When these variables are used in expressions, we will only copy 1 of the "foo_t" definitions over into the expression AST context so things normally work out. If you tried to cast something to a "foo_t" you would run into problems though since the type would be ambiguous. > > I have a problem that one DW_TAG_partial_unit can be included by multiple > DW_TAG_compile_unit. Therefore DWARFCompileUnit for DW_TAG_partial_unit > itself cannot map itself by SymbolFileDWARFDebugMap to its parent > DWARFCompileUnit for DW_TAG_compile_unit (as it has multiple parents). > > I expect you cannot link a single MacOS object file into two diferent > programs/libraries which are debugged at once by LLDB. You can. We always open a new instance of the .o file, one for each SymbolFileDWARFDebugMap or unique executable that refers to the .o file. > > > >> One other idea is to keep all DWARF files separate and stand alone. Your >> main DWARF file with one or more DW_TAG_imported_unit and all >> DW_TAG_imported_unit referenced files, each as its own SymbolFileDWARF. Any >> reference to a DW_FORM_ref_alt would turn into a forward declaration in the >> current SymbolFileDWARF, so the ASTContext in each SymbolFileDWARF wouldn't >> know anything about the types, > > Is it applicable even if DW_TAG_imported_unit points to DW_TAG_partial_unit's > containing DW_TAG_variable, DW_TAG_subprogram and arbitrary other DIEs, not > just types? This approach will not work if that is the case. Scratch the above idea... > > >> The other approach I might suggest is to write a DWARF linker, maybe using >> LLVM's DWARF classes (see llvm-dsymutil sources) that takes the top level >> DWARF and all DW_TAG_imported_unit files and combines them all back into one >> large DWARF file. > > That would defeat the advantage of DWZ-optimized debug info files. DWZ > reduces their size by approx. 30%. If the relinking was made on-demand then > it defeats the LLDB performance advantage over GDB - GDB can already read DWZ > natively (GDB does duplicates the internal representation when reading DWZ > CUs/PUs). In such case I could already code such reconstruction of non-DWZ > debug info when reading m_die_array - but that also seems needlessly slow to > me. DWZ should bring even performance advantage of parsing the DWZ common > file (=imported file) only once. > > >> One other idea is to let each DWARF file be separate, and when you need >> a type from a DW_TAG_imported_unit you log that file as stand alone and copy >> the type from its clang::ASTContext into the main SymbolFileDWARF's AST >> context. We copy types all the time in expressions as each on has its own >> AST context. > > Does this work even for non-type DIEs? No it does not. Only types are fine, but anything else will fall down. > > >> So there are many solutions. I would vote for linking the DWARF into >> a single f
Re: [lldb-dev] Difficulty in using target.source-map to map source files
Hi Jim,
Thanks for the valuable reply. Please find my comments inline.
Regards,
Karan
On Wed, Aug 23, 2017 at 12:32 AM, Jim Ingham wrote:
>
> > On Aug 21, 2017, at 12:02 PM, karnajit wangkhem via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi All,
> >
> > Below is a sample example, where target.source-map seems to have a
> limitation. The limitation seems to be because
> > 1. lldb does not have an equivalent command like directory in gdb
>
> The gdb "dir" command seemed always to be more annoying than useful in
> real situations. If your project had any complexity in the directory
> structure you ended up having to add dir commands for all the
> subdirectories, which got tedious quickly. Since you pretty much always
> move your sources around rigidly, "source maps" are a more natural way to
> specify this.
>
> Note, we could add a recursive "dir" command, but you can't do the
> simpleminded recursive search or you'll mess up when the sources have same
> named files in different directories. Because of this, again the source
> maps seem more suited.
>
>
-- Really a good info to know. Thanks!
> > 2. target.source-map does not accept multiple mapping entries. I checked
> this only with freebsd.
> >
> > (lldb) settings show target.source-map
> > target.source-map (path-map) =
> > [0] "/home/karnajitw/lldb_test_execs/test_source_line1" ->
> "/u/test/test_source_line1"
>
> That is not correct:
>
> (lldb) settings set target.source-map /some/source/path /tmp
> /some/other/source/path /tmp
> (lldb) settings show target.source-map
> target.source-map (path-map) =
> [0] "/some/source/path" -> "/tmp"
> [1] "/some/other/source/path" -> "/tmp"
>
> or
>
> (lldb) set set target.source-map /some/source/path /tmp
> (lldb) set append target.source-map /some/other/source/path /tmp
> (lldb) set show target.source-map
> target.source-map (path-map) =
> [0] "/some/source/path" -> "/tmp"
> [1] "/some/other/source/path" -> "/tmp"
>
- Thanks! This helped.
> >
> > 3. Haven't checked in the code yet, but if we see the mappings of
> scenario 1, they all point to a single real path
> /home/karnajitw/lldb_test_execs/test_source_line1. But looks like the
> mapping logic only considers strings into account. But, at the same time, I
> am not claiming that they should be interpreted as path from a different
> machine during the mapping.
> >
>
> I'm not sure what you mean here. lldb does what it can to unwind the
> source path, but it doesn't assume that those paths actually exist locally,
> so the most it can do is remove redundant "/"-s and "/./"-s and unwind
> ".."-s. We do this before most source path comparisons (it's part of the
> FileSpec Equals method). We've been tinkering with this over time so make
> sure you are using a recent version of lldb. If there are places where we
> don't do this, then that's easily fixed.
>
>
- Your answer is in line with what I wanted to know. My lldb should be
quite recent. But I used it only for freebsd currently.
% ./lldb --version
lldb version 5.0.0 (http://llvm.org/svn/llvm-project/lldb/trunk revision
305778)
clang revision 305546
llvm revision 305548
>
> > I want to check on this issue in-depth. But before that, want to confirm
> if this is real issue or there are other ways to deal these scenarios which
> I am not aware of?
> >
> > I am referring below link for the lldb commands.
> > https://lldb.llvm.org/lldb-gdb.html
> >
> > 1. First scenario: Different souce file path representation
> >
> > [/home/karnajitw/lldb_test_execs/test_source_line1] $ clang -O0 -g
> /home/karnajitw/lldb_test_execs///test_source_line1/main.c
> /home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1/a/ainc.c
> /home/karnajitw/lldb_test_execs/test_source_line1/a/b/binc.c
> >
> > Machine 1: /home/karnajitw/lldb_test_execs/test_source_line1 -> Machine
> 2: /u/test/test_source_line1
> >
> > test_source_line1
> > |-- a
> > | |-- ainc.c
> > | |-- ainc.h
> > | `-- b
> > | |-- binc.c
> > | `-- binc.h
> > |-- a.out
> > `-- main.c
> >
> > % ./lldb test_source_line1/a.out
> >
> > (lldb) target create "test_source_line1/a.out"
> > Current executable set to 'test_source_line1/a.out' (x86_64).
> > (lldb) l main
> > File: /home/karnajitw/lldb_test_execs///test_source_line1/main.c
> > (lldb) l afn
> > File: /home/karnajitw/lldb_test_execs/../lldb_test_execs/test_sour
> ce_line1/a/ainc.c
> > (lldb) l bfn
> > File: /home/karnajitw/lldb_test_execs/test_source_line1/a/b/binc.c
> >
> > (lldb) settings set target.source-map
> > /home/karnajitw/lldb_test_execs///test_source_line1
> /u/test/test_source_line1
> >
> > (lldb) l main
> > File: /home/karnajitw/lldb_test_execs///test_source_line1/main.c
> >1#include "a/ainc.h"
> >2
> >3int main()
> >4{
> >5 afn();
> >6
> >7 bfn();
> >8
> >9 return 0;
> >10 }
> > (lldb) l afn
> > File: /home/karnajitw/lldb_test_execs/../lldb_test_execs/test_sour
> ce_line1/a/ainc.c
>
Re: [lldb-dev] Remote debugging ARM target from x86 host
> On Aug 24, 2017, at 8:33 AM, Ted Woodward wrote:
>
> The lldb-server launch line looks ok; it should take the port 0 arg and get a
> port from the OS.
> lldb is getting the port back from lldb-server in 4.0.1, as seen here:
>
>> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 56543
>> port
>
> But for 5.0.0 we see it fail the debugserver launch, and get:
>
>> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 0 port
>
> That log message comes right after the pipe read, which succeeds because
> error.Success() is true:
>
>// Read port from pipe with 10 second timeout.
>error = socket_pipe.ReadWithTimeout(
>port_cstr, num_bytes, std::chrono::seconds{10}, num_bytes);
>if (error.Success() && (port != nullptr)) {
> assert(num_bytes > 0 && port_cstr[num_bytes - 1] == '\0');
> uint16_t child_port = StringConvert::ToUInt32(port_cstr, 0);
> if (*port == 0 || *port == child_port) {
>*port = child_port;
>if (log)
> log->Printf("GDBRemoteCommunication::%s() "
> "debugserver listens %u port",
> __FUNCTION__, *port);
>
> As an aside, I don't like that assert - if we get garbage back from the pipe,
> we should error out, not take down lldb.
The assert should be removed and the code should work correctly without the
assert.
> Another aside, the definition of port_cstr is odd:
>char port_cstr[PATH_MAX] = {0};
>port_cstr[0] = '\0';
> The size is way to big - max port number is 65535, so we don't need PATH_MAX
> bytes. And 2 assignments to make it a null string?
>
>
> Ramana, can you stick in a log message to print port_cstr? I suspect it's
> actually getting 0 back from lldb-server, which would tell us the error is in
> the server code, not the client code.
>
With the following args:
argv[0]="/mnt/var/binaries/arm_release/bin/lldb-server"
argv[1]="gdbserver"
argv[2]="tcp://10.10.12.3:0"
argv[3]="--native-regs"
argv[4]="--pipe"
argv[5]="7"
argv[6]=NULL
lldb-server should bind to port 0, figure out the port, and write the port
number into the file descriptor 7 ("--pipe 7" argument) to let the other side
know what port to report back to the remote LLDB. The reply to the
qLaunchGDBServer packet should then contain this valid port number.
Ted's comments are correct and I am guessing we will find the "lldb-server
gdb-server" is not doing the right thing and it isn't returning the correctly
bound port.
When we are doing remote stuff we must use TCP so there should be lldb-server
should be opening a TCP socket, binding, listening and accepting a connection
from the remote LLDB.
Greg
> Ted
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>> -Original Message-
>> From: Ramana [mailto:ramana.venka...@gmail.com]
>> Sent: Thursday, August 24, 2017 4:00 AM
>> To: Ted Woodward
>> Cc: Greg Clayton ; Hans Wennborg
>> ; lldb-dev@lists.llvm.org
>> Subject: Re: [lldb-dev] Remote debugging ARM target from x86 host
>>
>> Greg, Ted
>>
>> Thanks for your comments.
>>
>> On Thu, Aug 24, 2017 at 12:01 AM, Ted Woodward
>> wrote:
>>>
>>> What should be happening is Handle_qLaunchGDBServer calls
>> LaunchGDBServer with a port of UINT16_MAX, which tells it to use a port in
>> its
>> port list. It shouldn't have a port list, so should return 0.
>> LaunchGDBServer calls
>> StartDebugServerProcess with a port of 0 in the url. StartDebugServerProcess
>> launches the gdbserver with a named pipe, and reads the actual port from the
>> pipe.
>>
>> Yes, the port list is empty unless --(min/max)-gdbserver-port is specified
>> and
>> the gdbserver reads port number from the named pipe which in the failing case
>> is zero.
>>
>>> I suggest turning on more logging - specifically, "gdb-remote process".
>>> That's
>> the channel used in StartDebugServerProcess.
>>>
>>
>> In fact I have given the relevant log line of "gdb-remote process" in the bug
>> details reporting port zero. Anyhow, the full log of "gdb-remote process" for
>> both lldb v4.0.1 and v5.0.0 is given at the bottom of my reply.
>>
>> I thought https://reviews.llvm.org/rL295947 (Ensure lldb-server waits for
>> child
>> debug servers to start up when passing them) got something to do with this
>> bug
>> but both reversing
>>
>>if (pass_comm_fd == -1) { at
>> source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:1086
>>
>> to original
>>
>> if (pass_comm_fd == -1 && ((port != nullptr && *port == 0) || port ==
>> nullptr)) {
>>
>> and
>>
>>increasing the time out to 30 sec from 10 sec in
>> socket_pipe.ReadWithTimeout()at
>> source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:1255
>>
>> did not solve the issue.
>>
>> By the way, the remote debugging of x86 (linux) from x86 (linux) with
Re: [lldb-dev] RFC for DWZ = DW_TAG_imported_unit + DWARF-5 supplementary files
On Wed, 23 Aug 2017 23:55:00 +0200, Greg Clayton wrote: > > On Aug 23, 2017, at 2:06 PM, Jan Kratochvil via lldb-dev > > wrote: > > Currently it always has to as on non-OSX platforms it is using > > DWARFCompileUnit::Index(). But as I plan to implement DWARF-5 .debug_names > > index (like __apple_* index) maybe LLDB then no longer needs to populate > > m_die_array and so just expanding all DW_TAG_partial_unit into a single > > m_die_array for each DW_TAG_compile_unit is fine? > > So I glossed over the documentation and I gathered that DWARF type info > might be stored in other DWARF files and references from the current file. Yes. Arbitrary DIEs, not just type-defining DIEs. DW_TAG_imported_unit can happen anywhere according to the DWARF standard but for the DWZ/Fedora case it is a bit simpler one can limit the support for only DW_TAG_imported_unit with parent of DW_TAG_compile_unit (or DW_TAG_partial_unit for nested imports). DWZ ever uses DW_TAG_imported_unit only at the CU/PU top level. > SymbolFileDWARFDebugMap is an example of how we do things on MacOS. We have > one clang::ASTContext in the SymbolFileDWARFDebugMap, and multiple external > .o files (where each ins a SymbolFileDWARF instance) that contain unlinked > DWARF. Each SymbolFileDWARF instance will have: > > void SymbolFileDWARF::SetDebugMapModule(const lldb::ModuleSP &module_sp); > > called to indicate it is actually part of the SymbolFileDWARFDebugMap. > Then there are functions that check the debug map file and return the > UniqueDWARFASTTypeMap or the TypeSystem from the SymbolFileDWARFDebugMap if > we have one: Therefore IIUC you make a single context for all types from a compiled program? Primitive (non-class) types can be different across CUs: CU1: typedef int foo_t; CU2: typedef long foo_t; I have a problem that one DW_TAG_partial_unit can be included by multiple DW_TAG_compile_unit. Therefore DWARFCompileUnit for DW_TAG_partial_unit itself cannot map itself by SymbolFileDWARFDebugMap to its parent DWARFCompileUnit for DW_TAG_compile_unit (as it has multiple parents). I expect you cannot link a single MacOS object file into two diferent programs/libraries which are debugged at once by LLDB. > One other idea is to keep all DWARF files separate and stand alone. Your > main DWARF file with one or more DW_TAG_imported_unit and all > DW_TAG_imported_unit referenced files, each as its own SymbolFileDWARF. Any > reference to a DW_FORM_ref_alt would turn into a forward declaration in the > current SymbolFileDWARF, so the ASTContext in each SymbolFileDWARF wouldn't > know anything about the types, Is it applicable even if DW_TAG_imported_unit points to DW_TAG_partial_unit's containing DW_TAG_variable, DW_TAG_subprogram and arbitrary other DIEs, not just types? > The other approach I might suggest is to write a DWARF linker, maybe using > LLVM's DWARF classes (see llvm-dsymutil sources) that takes the top level > DWARF and all DW_TAG_imported_unit files and combines them all back into one > large DWARF file. That would defeat the advantage of DWZ-optimized debug info files. DWZ reduces their size by approx. 30%. If the relinking was made on-demand then it defeats the LLDB performance advantage over GDB - GDB can already read DWZ natively (GDB does duplicates the internal representation when reading DWZ CUs/PUs). In such case I could already code such reconstruction of non-DWZ debug info when reading m_die_array - but that also seems needlessly slow to me. DWZ should bring even performance advantage of parsing the DWZ common file (=imported file) only once. > One other idea is to let each DWARF file be separate, and when you need > a type from a DW_TAG_imported_unit you log that file as stand alone and copy > the type from its clang::ASTContext into the main SymbolFileDWARF's AST > context. We copy types all the time in expressions as each on has its own > AST context. Does this work even for non-type DIEs? > So there are many solutions. I would vote for linking the DWARF into > a single file much like we do with llvm-dsymutil on Mac, but that really > depends if the type uniquing is desired within a single DWARF file and not > across many shared libraries that all reference common DW_TAG_imported_unit > files. I agree the DWZ optimization does primarily what -fdebug-types-section does. I do not see why to really do relinking files on disk, debugger should not need that to read the debug info. I do not fully understand why you do the llvm-dsymutil relinking when you already have SymbolFileDWARFDebugMap in LLDB. But I do not know OSX/Mac. Thanks, Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Remote debugging ARM target from x86 host
The lldb-server launch line looks ok; it should take the port 0 arg and get a
port from the OS.
lldb is getting the port back from lldb-server in 4.0.1, as seen here:
> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 56543
> port
But for 5.0.0 we see it fail the debugserver launch, and get:
> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 0 port
That log message comes right after the pipe read, which succeeds because
error.Success() is true:
// Read port from pipe with 10 second timeout.
error = socket_pipe.ReadWithTimeout(
port_cstr, num_bytes, std::chrono::seconds{10}, num_bytes);
if (error.Success() && (port != nullptr)) {
assert(num_bytes > 0 && port_cstr[num_bytes - 1] == '\0');
uint16_t child_port = StringConvert::ToUInt32(port_cstr, 0);
if (*port == 0 || *port == child_port) {
*port = child_port;
if (log)
log->Printf("GDBRemoteCommunication::%s() "
"debugserver listens %u port",
__FUNCTION__, *port);
As an aside, I don't like that assert - if we get garbage back from the pipe,
we should error out, not take down lldb.
Another aside, the definition of port_cstr is odd:
char port_cstr[PATH_MAX] = {0};
port_cstr[0] = '\0';
The size is way to big - max port number is 65535, so we don't need PATH_MAX
bytes. And 2 assignments to make it a null string?
Ramana, can you stick in a log message to print port_cstr? I suspect it's
actually getting 0 back from lldb-server, which would tell us the error is in
the server code, not the client code.
Ted
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
> -Original Message-
> From: Ramana [mailto:ramana.venka...@gmail.com]
> Sent: Thursday, August 24, 2017 4:00 AM
> To: Ted Woodward
> Cc: Greg Clayton ; Hans Wennborg
> ; lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Remote debugging ARM target from x86 host
>
> Greg, Ted
>
> Thanks for your comments.
>
> On Thu, Aug 24, 2017 at 12:01 AM, Ted Woodward
> wrote:
> >
> > What should be happening is Handle_qLaunchGDBServer calls
> LaunchGDBServer with a port of UINT16_MAX, which tells it to use a port in its
> port list. It shouldn't have a port list, so should return 0. LaunchGDBServer
> calls
> StartDebugServerProcess with a port of 0 in the url. StartDebugServerProcess
> launches the gdbserver with a named pipe, and reads the actual port from the
> pipe.
>
> Yes, the port list is empty unless --(min/max)-gdbserver-port is specified and
> the gdbserver reads port number from the named pipe which in the failing case
> is zero.
>
> > I suggest turning on more logging - specifically, "gdb-remote process".
> > That's
> the channel used in StartDebugServerProcess.
> >
>
> In fact I have given the relevant log line of "gdb-remote process" in the bug
> details reporting port zero. Anyhow, the full log of "gdb-remote process" for
> both lldb v4.0.1 and v5.0.0 is given at the bottom of my reply.
>
> I thought https://reviews.llvm.org/rL295947 (Ensure lldb-server waits for
> child
> debug servers to start up when passing them) got something to do with this bug
> but both reversing
>
> if (pass_comm_fd == -1) { at
> source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:1086
>
> to original
>
>if (pass_comm_fd == -1 && ((port != nullptr && *port == 0) || port ==
> nullptr)) {
>
> and
>
> increasing the time out to 30 sec from 10 sec in
> socket_pipe.ReadWithTimeout()at
> source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:1255
>
> did not solve the issue.
>
> By the way, the remote debugging of x86 (linux) from x86 (linux) with lldb
> v5.0.0 (but works with v4.0.1) also fails with assertion
>
> assert(num_bytes > 0 && port_cstr[num_bytes - 1] == '\0'); at
> source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:1258
>
> due to the reason that socket_pipe.ReadWithTimeout() could not successfully
> read the port number from the named pipe.
>
> Based on the above, though I am not sure, the other patch I could think of
> having an effect on this bug is
> https://reviews.llvm.org/rL300579 (Update LLDB Host to support IPv6 over TCP)
> which changed the socket implementation.
>
>
> lldb-server log for "gdb-remote process" with lldb v4.0.1 (passing case)
>
> GDBRemoteCommunication::StartDebugserverProcess(url=tcp://10.10.12.3:0,
> port=0)
> GDBRemoteCommunication::StartDebugserverProcess() found gdb-remote stub
> exe '/mnt/var/binaries/arm_release/bin/lldb-server'
> launch info for gdb-remote stub:
> Executable: lldb-server
> Triple: *-*-*
> Arguments:
> argv[0]="/mnt/var/binaries/arm_release/bin/lldb-server"
> argv[1]="gdbserver"
> argv[2]="tcp://10.10.12.3:0"
> argv[3]="--native-regs"
> argv[4]="--pipe"
> argv[5]="7"
> argv[6]=NU
Re: [lldb-dev] Remote debugging ARM target from x86 host
Greg, Ted
Thanks for your comments.
On Thu, Aug 24, 2017 at 12:01 AM, Ted Woodward
wrote:
>
> What should be happening is Handle_qLaunchGDBServer calls LaunchGDBServer
> with a port of UINT16_MAX, which tells it to use a port in its port list. It
> shouldn't have a port list, so should return 0. LaunchGDBServer calls
> StartDebugServerProcess with a port of 0 in the url. StartDebugServerProcess
> launches the gdbserver with a named pipe, and reads the actual port from the
> pipe.
Yes, the port list is empty unless --(min/max)-gdbserver-port is
specified and the gdbserver reads port number from the named pipe
which in the failing case is zero.
> I suggest turning on more logging - specifically, "gdb-remote process".
> That's the channel used in StartDebugServerProcess.
>
In fact I have given the relevant log line of "gdb-remote process" in
the bug details reporting port zero. Anyhow, the full log of
"gdb-remote process" for both lldb v4.0.1 and v5.0.0 is given at the
bottom of my reply.
I thought https://reviews.llvm.org/rL295947 (Ensure lldb-server waits
for child debug servers to start up when passing them) got something
to do with this bug but both reversing
if (pass_comm_fd == -1) { at
source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:1086
to original
if (pass_comm_fd == -1 && ((port != nullptr && *port == 0) || port
== nullptr)) {
and
increasing the time out to 30 sec from 10 sec in
socket_pipe.ReadWithTimeout()at
source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:1255
did not solve the issue.
By the way, the remote debugging of x86 (linux) from x86 (linux) with
lldb v5.0.0 (but works with v4.0.1) also fails with assertion
assert(num_bytes > 0 && port_cstr[num_bytes - 1] == '\0'); at
source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:1258
due to the reason that socket_pipe.ReadWithTimeout() could not
successfully read the port number from the named pipe.
Based on the above, though I am not sure, the other patch I could
think of having an effect on this bug is
https://reviews.llvm.org/rL300579 (Update LLDB Host to support IPv6
over TCP) which changed the socket implementation.
lldb-server log for "gdb-remote process" with lldb v4.0.1 (passing case)
GDBRemoteCommunication::StartDebugserverProcess(url=tcp://10.10.12.3:0, port=0)
GDBRemoteCommunication::StartDebugserverProcess() found gdb-remote
stub exe '/mnt/var/binaries/arm_release/bin/lldb-server'
launch info for gdb-remote stub:
Executable: lldb-server
Triple: *-*-*
Arguments:
argv[0]="/mnt/var/binaries/arm_release/bin/lldb-server"
argv[1]="gdbserver"
argv[2]="tcp://10.10.12.3:0"
argv[3]="--native-regs"
argv[4]="--pipe"
argv[5]="7"
argv[6]=NULL
Environment:
env[0]="XDG_SESSION_ID=c3"
env[1]="TERM=xterm-256color"
env[2]="SHELL=/bin/sh"
env[3]="SSH_CLIENT=10.10.33.99 53542 22"
env[4]="SSH_TTY=/dev/pts/0"
env[5]="USER=root"
env[6]="MAIL=/var/mail/root"
env[7]="PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin"
env[8]="PWD=/home/root"
env[9]="EDITOR=vi"
env[10]="PS1=\u@\h:\w\$ "
env[11]="SHLVL=1"
env[12]="HOME=/home/root"
env[13]="LOGNAME=root"
env[14]="SSH_CONNECTION=10.10.33.99 53542 10.10.2.4 22"
env[15]="XDG_RUNTIME_DIR=/run/user/0"
env[16]="_=/mnt/var/binaries/arm_release/bin/lldb-server"
env[17]=NULL
GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 56543 port
lldb-server log for "gdb-remote process" with lldb v5.0.0 (failing case)
GDBRemoteCommunication::StartDebugserverProcess(url=tcp://10.10.12.3:0, port=0)
GDBRemoteCommunication::StartDebugserverProcess() found gdb-remote
stub exe '/mnt/var/binaries/arm_v5.0_orig/bin/lldb-server'
launch info for gdb-remote stub:
Executable: lldb-server
Triple: *-*-*
Arguments:
argv[0]="/mnt/var/binaries/arm_v5.0_orig/bin/lldb-server"
argv[1]="gdbserver"
argv[2]="tcp://10.10.12.3:0"
argv[3]="--native-regs"
argv[4]="--pipe"
argv[5]="7"
argv[6]=NULL
Environment:
env[0]="XDG_SESSION_ID=c3"
env[1]="TERM=xterm-256color"
env[2]="SHELL=/bin/sh"
env[3]="SSH_CLIENT=10.10.33.99 53542 22"
env[4]="SSH_TTY=/dev/pts/0"
env[5]="USER=root"
env[6]="MAIL=/var/mail/root"
env[7]="PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin"
env[8]="PWD=/home/root"
env[9]="EDITOR=vi"
env[10]="PS1=\u@\h:\w\$ "
env[11]="SHLVL=1"
env[12]="HOME=/home/root"
env[13]="LOGNAME=root"
env[14]="SSH_CONNECTION=10.10.33.99 53542 10.10.2.4 22"
env[15]="XDG_RUNTIME_DIR=/run/user/0"
env[16]="_=/mnt/var/binaries/arm_v5.0_orig/bin/lldb-server"
env[17]=NULL
GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 0 port
Thanks,
Ramana
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>> -Original Message-
>> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg
>> Clayton via lldb-dev
>> Sent: Wednesday, August 23, 2017 12:45 PM
>> To: Hans Wennborg
>> Cc: Ramana ; LLDB Dev >
