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

Wed Oct 19 16:21:24 PDT 2016

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 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/d8eb9c74/attachment-0001.html>