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

Eric Christopher via lldb-dev lldb-dev at lists.llvm.org
Thu Oct 20 10:36:23 PDT 2016


Got it, thanks!

On Thu, Oct 20, 2016, 2:26 AM Pavel Labath <labath at google.com> wrote:

> Our buildbot <
> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake>
> runs the test suite with a selection of compilers, one of which is
> clang ToT (test3, test4). You should get an email from it if anything
> breaks.
>
> pl
>
> On 20 October 2016 at 00:24, Eric Christopher via lldb-dev
> <lldb-dev at lists.llvm.org> wrote:
> >
> >
> > 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>
> >
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20161020/4da2c5ec/attachment-0001.html>


More information about the lldb-dev mailing list