On Wed, Oct 19, 2016 at 4:09 PM, Eric Christopher <echri...@gmail.com> wrote:
> > On Wed, Oct 19, 2016 at 3:34 PM Tim Hammerquist <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? > Yes, these programs set up an expected state, and the python testsuite uses the lldb is used to debug these inferiors. So it looks like we want two scenarios: Scenario 1: build ToT lldb + llvm/clang/etc using Xcode toolchain; build test programs AND inferiors using Xcode toolchain Scenario 2: build ToT lldb + llvm/clang/etc using ToT compiler; build test programs AND inferiors using ToT compiler Does that sound right? S1 is _nearly_ what we have now; it would only require modifying the python test suite to build inferiors with the system compiler. I can start looking at what's required to start S2. We've got some hardware coming to make it easier to bring up. -Tim 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> >> wrote: >> >> >> >> On Wed, Oct 19, 2016 at 3:26 PM Tim Hammerquist <pen...@gmail.com> wrote: >> >> The LLDB job in 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 >> >> 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 >> >> >> This seems like something that should be fixed :) >> >> -eric >> >> >> >> -Tim >> >> On Wed, Oct 19, 2016 at 2:36 PM, Eric Christopher <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> 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> wrote: >> > >> > This might affect us. Do we handle it correctly? >> > >> > 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 >> > 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 >> >> >> >> >> -- >> Tim <pen...@gmail.com> >> >> >> >> >> -- >> Tim <pen...@gmail.com> >> > -- Tim <pen...@gmail.com>
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
