> On Oct 20, 2016, at 1:00 PM, Tamas Berghammer via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > Building LLDB with cmake is already supported on all operating systems > (including Darwin) for a while so that shouldn't be a blocker.
While this is technically true, the LLDB test suite makes a lot of assumptions that if you’re on Darwin you built with Xcode, which results in lots of tests not executing at all. -Chris > > On Thu, Oct 20, 2016 at 8:09 PM Tim Hammerquist via lldb-dev > <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote: > IIRC, the only reason the LLDB python test suite uses the in-tree compiler > (Scenario 1) was so to test sanitizers before they were available in the > system compiler. If that's the case, then using Xcode 8 on the builder will > allow both the LLDB build and tests to use the system compiler. > > As I understand it, there are a few ways to go about building lldb using the > ToT (or at least, last green) compiler. This approach will be of limited use > until building lldb with cmake is supported, however. I'm following up on > this timeline. > > -Tim > > > On Thu, Oct 20, 2016 at 11:50 AM, Ted Woodward <ted.woodw...@codeaurora.org > <mailto:ted.woodw...@codeaurora.org>> wrote: > I think a hardcoded value of 1 for maximum_operations_per_instruction will > work like it does today – 1 linetable entry per Hexagon packet, which may > have 1-4 instructions in it. Hexagon executes 1 packet at a time, so anywhere > from 1-4 instructions at once. > > > > At O0, the compiler doesn’t packetize instructions, so 1 instruction is run > at a time. At 01 it will, but it doesn’t do many other optimizations. We > should still have 1 line per packet. O2 and O3 can move instructions around, > so will have up to 4 source lines in 1 packet. I think we’ll need to > experiment internally with what that means for the debugger, once we get this > change. > > > > -- > > Qualcomm Innovation Center, Inc. > > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > > > > From: Eric Christopher [mailto:echri...@gmail.com > <mailto:echri...@gmail.com>] > Sent: Wednesday, October 19, 2016 6:09 PM > To: Tim Hammerquist <pen...@gmail.com <mailto:pen...@gmail.com>> > Cc: Greg Clayton <gclay...@apple.com <mailto:gclay...@apple.com>>; Ted > Woodward <ted.woodw...@codeaurora.org <mailto:ted.woodw...@codeaurora.org>>; > LLDB <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> > Subject: Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4 > > > > > > On Wed, Oct 19, 2016 at 3:34 PM Tim Hammerquist <pen...@gmail.com > <mailto:pen...@gmail.com>> wrote: > > I was mistaken. > > > > The system toolchain builds stage1 llvm, clang & co. > > The system toolchain builds lldb containing the llvm/clang/etc bits. > > The system toolchain builds gtest test programs. > > The stage1 compiler builds the python test inferiors. > > > > > > OK, then it sounds like at least some of the test programs are built with the > new compiler? IIRC the python test inferiors here are the programs that are > the meat of the testsuite for lldb yes? > > > > If so, then on check-in we should possibly see some difference on some bot if > they all use the same general configuration. I don't have a current checkout > so I don't know if the default -g is used or if it's set to a different dwarf > level. Currently it looks like clang will use dwarf4 by default with -g: > > > > echristo@dzur ~/tmp> ~/builds/build-llvm/bin/clang -c foo.c -o - -target > x86_64-apple-macosx10.11 -g | llvm-dwarfdump - | grep version | grep -v clang > > 0x00000000: Compile Unit: length = 0x00000037 version = 0x0004 abbr_offset = > 0x0000 addr_size = 0x08 (next unit at 0x0000003b) > > version: 2 > > > > where the first line is the debug_info header and the second is the version > in the line table. > > > > Ted/Greg: Relatedly, what brought this up was the vliw aspect with > maximum_operations_per_instruction - it's being hard coded to 1 here and I'm > not sure how we want to deal with that on hexagon? Currently it'll be hard > set to 1 so line stepping will work as I imagine it currently does. That > said, if we wanted to take advantage of it then that's different. Primarily I > wasn't sure if Ted and folk had a debugger that did take advantage of it if > it was there. > > > > Thanks! > > > > -eric > > > > > > On Wed, Oct 19, 2016 at 3:28 PM, Eric Christopher <echri...@gmail.com > <mailto:echri...@gmail.com>> wrote: > > > > On Wed, Oct 19, 2016 at 3:26 PM Tim Hammerquist <pen...@gmail.com > <mailto:pen...@gmail.com>> wrote: > > The LLDB job in llvm.org <http://llvm.org/> will build a stage1 RA with > llvm+clang+libcxx+compiler-rt using the system compiler, and use the new > compiler to build lldb. > > > > By default, this is kicked off automatically when a clang stage1 RA is > successful, but can be manually triggered to build HEAD, or any revision > desired. > > > > The python test suite (invoked with the xcodebuild target > lldb-python-test-suite) uses the newly built compiler to build its test > programs. > > > > http://lab.llvm.org:8080/green/job/lldb_build_test/21202/consoleFull#console-section-4 > > <http://lab.llvm.org:8080/green/job/lldb_build_test/21202/consoleFull#console-section-4> > > > However, the gtest suite (target lldb-gtest) uses the system (Xcode > toolchain) compiler to build test programs. > > > > http://lab.llvm.org:8080/green/job/lldb_build_test/21202/artifact/lldb/test_output.zip > > <http://lab.llvm.org:8080/green/job/lldb_build_test/21202/artifact/lldb/test_output.zip> > > > > > This seems like something that should be fixed :) > > > > -eric > > > > > > -Tim > > > > On Wed, Oct 19, 2016 at 2:36 PM, Eric Christopher <echri...@gmail.com > <mailto:echri...@gmail.com>> wrote: > > From chatting with Tim it sounds like at least one lldb bot uses the ToT > compiler - we should probably verify that not only does it use that to build > lldb but uses it for the tests. That'll get us at least some testing here. > > > > -eric > > > > On Wed, Oct 19, 2016 at 12:55 PM Greg Clayton via lldb-dev > <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote: > > I believe we are good, but it would be good to verify via testing once a > compiler becomes available. > > Greg > > > On Oct 19, 2016, at 12:19 PM, Ted Woodward via lldb-dev > > <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote: > > > > This might affect us. Do we handle it correctly? > > > > https://reviews.llvm.org/D16697 <https://reviews.llvm.org/D16697> > > > > -- > > Qualcomm Innovation Center, Inc. > > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > > Linux Foundation Collaborative Project > > > > _______________________________________________ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> > > > > > -- > > Tim <pen...@gmail.com <mailto:pen...@gmail.com>> > > > > > > > -- > > Tim <pen...@gmail.com <mailto:pen...@gmail.com>> > > > > > -- > Tim <pen...@gmail.com <mailto:pen...@gmail.com>> > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
