[lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

[Eric Christopher via lldb-dev]

On Wed, Oct 19, 2016 at 4:21 PM Tim Hammerquist <penryu at gmail.com> wrote:

> On Wed, Oct 19, 2016 at 4:09 PM, Eric Christopher <echristo at gmail.com>
> wrote:
>
>
> On Wed, Oct 19, 2016 at 3:34 PM Tim Hammerquist <penryu at 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'd think so. It makes sure that current lldb is going to continue to work
with both new compilers as well as existing compilers and that current lldb
is buildable with both current compilers and newer compilers.

Thanks!

-eric


> 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 at 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 <echristo at gmail.com>
> wrote:
>
>
>
> On Wed, Oct 19, 2016 at 3:26 PM Tim Hammerquist <penryu at 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 <echristo at 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 at 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 at 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 at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
>
> --
> Tim <penryu at gmail.com>
>
>
>
>
> --
> Tim <penryu at gmail.com>
>
>
>
>
> --
> Tim <penryu at gmail.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20161019/f2ea406d/attachment-0001.html>