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

2016-10-20 Thread Pavel Labath via lldb-dev 
Our buildbot 
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
 wrote:
>
>
> On Wed, Oct 19, 2016 at 4:21 PM Tim Hammerquist  wrote:
>>
>> On Wed, Oct 19, 2016 at 4:09 PM, Eric Christopher 
>> wrote:
>>>
>>>
>>> On Wed, Oct 19, 2016 at 3:34 PM Tim Hammerquist  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@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
>>> 0x: Compile Unit: length = 0x0037 version = 0x0004
>>> abbr_offset = 0x addr_size = 0x08 (next unit at 0x003b)
>>>  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 
 wrote:
>
>
>
> On Wed, Oct 19, 2016 at 3:26 PM Tim Hammerquist 
> 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 
>> 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
>>>  wrote:

 I believe we are good, but it would be good to verify via testing
>>>

Re: [lldb-dev] Regenerating public API reference documentation

2016-10-20 Thread Tamas Berghammer via lldb-dev 
As nobody had any objection I committed in the regeneration of the docs as
rL284725

For generating it automatically it would be great but as far as I know
currently the LLDB docs and the LLVM docs are generated and distributed in
a very different ways so it might be challenging to integrate (in case of
LLDB the HTML files are checked into the main lldb repository).

Tamas

On Fri, Oct 14, 2016 at 4:50 PM Mehdi Amini  wrote:


On Oct 14, 2016, at 6:44 AM, Tamas Berghammer via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

Hi All,

The current LLDB API reference documentation available at
http://lldb.llvm.org/python_reference/
 and at
http://lldb.llvm.org/cpp_reference/html/ but it haven't been updated since
July 2013.

I am planning to regenerate it next week using "ninja lldb-cpp-doc
lldb-python-doc" (from a Linux machine using epydoc 3.0.1 and doxygen
1.8.6) to get them up to date. Is there any objection against it?

Additionally, in the future it would be great if we can keep the generated
doc more up to date after additions to the SB API so users of LLDB can rely
it.


There is a bot continuously updating http://llvm.org/docs/ ; ideally we
should be able to hook the other LLVM sub-projects there.

—
Mehdi
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 30603] Python reference documentation is out of date

2016-10-20 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=30603

Tamas Berghammer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Tamas Berghammer  ---
The new version of the documentation have been committed as rL284725

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] lldb tracepoint support

2016-10-20 Thread Andras Fancsali via lldb-dev 
Hi,

Is it in plan to support trace point commands in the near future, similar way 
as the gdb does? 
https://sourceware.org/gdb/onlinedocs/gdb/Set-Tracepoints.html#Set-Tracepoints

Thanks,
Andras
National Instruments Romania S.R.L.
--
B-dul 21 Decembrie 1989, nr. 77, A2
Cluj-Napoca 400604, Romania
C.I.F.: RO17961616 | O.R.C.: J12/3337/2005
Telefon: +40 264 406428 | Fax: +40 264 406429
E-mail: office.c...@ni.com
Web: romania.ni.com

Vanzari si suport tehnic:
Telefon gratuit : 0800 070071
E-mail vanzari: ni.roma...@ni.com
E-mail suport tehnic: techsupp...@ni.com
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLDB support for python scripts in ELF section, like .debug_gdb_scripts in GDB

2016-10-20 Thread Richard Geary via lldb-dev 
Has LLDB considered adding per-binary support for LLDB python scripts,
eg. for adding custom type summaries?

This is the equivalent GDB feature
https://sourceware.org/gdb/onlinedocs/gdb/dotdebug_005fgdb_005fscripts-section.html

GDB can load a custom python script from either a side-installed file
or an ELF section.  This allows debugging of multiple binaries with
different implementations of the pretty-printer.

Any suggestions for LLDB workarounds would be welcome.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

2016-10-20 Thread Eric Christopher via lldb-dev 
Got it, thanks!

On Thu, Oct 20, 2016, 2:26 AM Pavel Labath  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
>  wrote:
> >
> >
> > On Wed, Oct 19, 2016 at 4:21 PM Tim Hammerquist 
> wrote:
> >>
> >> On Wed, Oct 19, 2016 at 4:09 PM, Eric Christopher 
> >> wrote:
> >>>
> >>>
> >>> On Wed, Oct 19, 2016 at 3:34 PM Tim Hammerquist 
> 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@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
> >>> 0x: Compile Unit: length = 0x0037 version = 0x0004
> >>> abbr_offset = 0x addr_size = 0x08 (next unit at 0x003b)
> >>>  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  >
>  wrote:
> >
> >
> >
> > On Wed, Oct 19, 2016 at 3:26 PM Tim Hammerquist 
> > 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
>

Re: [lldb-dev] LLDB support for python scripts in ELF section, like .debug_gdb_scripts in GDB

2016-10-20 Thread Greg Clayton via lldb-dev 
We currently have the ability to support this for ELf. It is only currently 
hooked up for Mach-O binaries when you have a dSYM (stand alone debug info 
bundle). You will want to implement this for your platform:

FileSpecList
Platform::LocateExecutableScriptingResources(Target *target, Module &module,
 Stream *feedback_stream) {
  return FileSpecList();
}

So given an LLDB Module (executable/shared library), find any python files that 
should be imported. You can take a look at what we do in PlatformDarwin:

PlatformDarwin::LocateExecutableScriptingResources()

Basically it sees if the module has a stand alone debug file, and if it does, 
it looks for scripting resource files that will be imported. In our case we 
might have and module whose path is "/tmp/a.out", we ask the symbol vendor to 
get the symbol file ("/tmp/a.out.dSYM"), and if it has one, this file is a 
bundle. Inside of this bundle we look for a "a_out.py" that is relative to the 
file. If that file exists, it will be pulled in automatically.

So this is possible to implement for other platforms. Seems like you can have 
".debug_lldb_python_scripts" section that could specify a relative (relative to 
the ELF file itself) or absolute path to scripting files that should be loaded 
when this binary gets loaded. So that shouldn't be too hard to implement. 

Let me know if you have any questions.

Greg

> On Oct 4, 2016, at 8:02 AM, Richard Geary via lldb-dev 
>  wrote:
> 
> Has LLDB considered adding per-binary support for LLDB python scripts,
> eg. for adding custom type summaries?
> 
> This is the equivalent GDB feature
> https://sourceware.org/gdb/onlinedocs/gdb/dotdebug_005fgdb_005fscripts-section.html
> 
> GDB can load a custom python script from either a side-installed file
> or an ELF section.  This allows debugging of multiple binaries with
> different implementations of the pretty-printer.
> 
> Any suggestions for LLDB workarounds would be welcome.
> ___
> 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

Re: [lldb-dev] LLDB support for python scripts in ELF section, like .debug_gdb_scripts in GDB

2016-10-20 Thread Enrico Granata via lldb-dev 
LLDB has a similar feature, except:

a) it tries to load python scripts from dSYM bundles. If you have debug info 
stored in foo.dSYM, it will look for foo.dSYM/Contents/Resources/Python/foo.py
As far as I know, dSYMs only exist on Apple systems, so clearly you would need 
to design something else to load from places other than such debug info bundles

b) the feature is off by default, but there's a setting you can tweak to enable 
it. That is due to security concerns
I have given some thought to ideas in that space (e.g. code-signatures for the 
script files) but no code exists to back those thoughts

> On Oct 4, 2016, at 8:02 AM, Richard Geary via lldb-dev 
>  wrote:
> 
> Has LLDB considered adding per-binary support for LLDB python scripts,
> eg. for adding custom type summaries?
> 
> This is the equivalent GDB feature
> https://sourceware.org/gdb/onlinedocs/gdb/dotdebug_005fgdb_005fscripts-section.html
> 
> GDB can load a custom python script from either a side-installed file
> or an ELF section.  This allows debugging of multiple binaries with
> different implementations of the pretty-printer.
> 
> Any suggestions for LLDB workarounds would be welcome.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

2016-10-20 Thread Ted Woodward via lldb-dev 
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] 
Sent: Wednesday, October 19, 2016 6:09 PM
To: Tim Hammerquist 
Cc: Greg Clayton ; Ted Woodward 
; LLDB 
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 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

0x: Compile Unit: length = 0x0037 version = 0x0004 abbr_offset = 
0x addr_size = 0x08 (next unit at 0x003b)

 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 mailto:echri...@gmail.com> > wrote:

 

On Wed, Oct 19, 2016 at 3:26 PM Tim Hammerquist mailto: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 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 
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 
> mailto: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-d

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

2016-10-20 Thread Tim Hammerquist via lldb-dev 
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 
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]
> *Sent:* Wednesday, October 19, 2016 6:09 PM
> *To:* Tim Hammerquist 
> *Cc:* Greg Clayton ; Ted Woodward <
> ted.woodw...@codeaurora.org>; LLDB 
> *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  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
>
> 0x: Compile Unit: length = 0x0037 version = 0x0004 abbr_offset
> = 0x addr_size = 0x08 (next unit at 0x003b)
>
>  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 
> wrote:
>
>
>
> On Wed, Oct 19, 2016 at 3:26 PM Tim Hammerquist  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 
> 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 wou

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

2016-10-20 Thread Tamas Berghammer via lldb-dev 
Building LLDB with cmake is already supported on all operating systems
(including Darwin) for a while so that shouldn't be a blocker.

On Thu, Oct 20, 2016 at 8:09 PM Tim Hammerquist via lldb-dev <
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> 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]
> *Sent:* Wednesday, October 19, 2016 6:09 PM
> *To:* Tim Hammerquist 
> *Cc:* Greg Clayton ; Ted Woodward <
> ted.woodw...@codeaurora.org>; LLDB 
> *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  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
>
> 0x: Compile Unit: length = 0x0037 version = 0x0004 abbr_offset
> = 0x addr_size = 0x08 (next unit at 0x003b)
>
>  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 
> wrote:
>
>
>
> On Wed, Oct 19, 2016 at 3:26 PM Tim Hammerquist  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 
> wrote:
>
> From chatting with Tim it sounds like at least one lldb bot uses the ToT
> compiler - we should pr

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

2016-10-20 Thread Chris Bieneman via lldb-dev 

> On Oct 20, 2016, at 1:00 PM, Tamas Berghammer via lldb-dev 
>  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 
> 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  > 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 
> ] 
> Sent: Wednesday, October 19, 2016 6:09 PM
> To: Tim Hammerquist mailto:pen...@gmail.com>>
> Cc: Greg Clayton mailto:gclay...@apple.com>>; Ted 
> Woodward mailto:ted.woodw...@codeaurora.org>>; 
> LLDB 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  > 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
> 
> 0x: Compile Unit: length = 0x0037 version = 0x0004 abbr_offset = 
> 0x addr_size = 0x08 (next unit at 0x003b)
> 
>  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  > wrote:
> 
>  
> 
> On Wed, Oct 19, 2016 at 3:26 PM Tim Hammerquist  > 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