Re: [lldb-dev] add custom vendor commands
> On Oct 18, 2016, at 6:43 PM, Clayton, Greg wrote: > > > On Oct 18, 2016, at 7:48 AM, Giusti, Valentina > wrote: > > > > Hi Greg, > > > > Thanks a lot for your reply, please find below my answers. > > > >> You can install new python commands that can do the job to work out > >> the details. > >> > >> http://lldb.llvm.org/python-reference.html > >> > >> See the section named "CREATE A NEW LLDB COMMAND USING A PYTHON > >> FUNCTION". > >> > >> You can basically install a new "intel" command and parse all of the > >> options "show mpx-bounds ..." or "set mpx-bounds ..." from within this new > command. > >> You can use the public LLDB API to look through the process and do > >> things. Let me know if you need any help with this. There is also a > >> API to add custom commands from C++ plug-ins. Enrico Granata did this > >> work and can answer more questions on that. Either way, both commands > >> (python and C++ plug-ins) have access to the public API for LLDB, so > >> the code you will write will use the same API. So I would stick with > >> python for > now to get things working. > >> > > > > I think I would rather start right away with the C++ approach. If I > > understand > correctly, it means to create a specific Intel plugin under the directory > source/Plugins and use the LLDB API to add the custom command. > > That is one way to do this, but any change you make will require a recompile > of > LLDB. > > The only external plug-ins we currently have with LLDB are for adding > commands. See the following code in our test suite where $(trunk) is the root > of > your LLDB checkout: > > $(trunk)/packages/Python/lldbsuite/test/functionalities/plugins/commands > > This show you how to compile a C++ plug-in that will be loaded by LLDB if it > is > placed in the right plug-in location. So this would allow you to distribute > a plug- > in that can work with existing released LLDB in case you care to do so. > Thanks for mentioning this, I will keep it in mind. However I think I prefer to implement a builtin command. > > > >> Some questions for you: > >> - How do plan on detecting that you have an intel processor? > > > > I thought of checking if the target architecture is either > > llvm::Triple::x86 or > llvm::Triple::x86_64. Do you think there is a better approach to this? > > I guess just checking for the "BNDCFGU" register is what you will need to do? > Yeah, I can probably skip the arch checking step. > > > >> - Do you need access to any process registers? If so, are these > >> registers thread specific? Are these registers available currently on > >> linux and > MacOS? > > > > I only need to access the MPX configuration register, BNDCFGU. As far as I > know, MacOS doesn't have MPX support, so I also didn't implement the MPX > support for MacOS in LLDB, which means it is only available in Linux at the > moment. > > > >> - How do you locate the BT? (or do you even need to?). Is there > >> symbol? Can you extract all values in the bounds table once you locate it? > >> > > > > The bound tables are allocated contiguously in the process memory, starting > from the Bound Directory address which is stored in the BNDCFGU register. > Therefore, in the plugin I only need to access this register, do the > appropriate > calculations and then access the process memory to get the requested bound > table entry. > > Great. This sounds easy to do. Just decide if you prefer a built in command > or to > create an external command shared library plug-in and you are all set to go! > Seems so, thanks! - Val Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb-mi stopped after '-target-select remote'
Hi!
I think it's okay that remote target is stopped when you connect to it.
Just skip it.
On Wed, Oct 19, 2016 at 8:14 AM, Chunseok Lee via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> I have noticed that lldb-mi stopped after executing "-target-select
> remote".
> My execution step is like:
> -
> $ lldb-server g --platform=remote-linux "*:1234"
>
> $ lldb-mi
> (gdb)
> -file-exec-and-symbols /home/twoflower/a.out
> (gdb)
> -target-select remote localhost:1234
> .
> (gdb)
> *stopped,reason="signal-received",signal-name="
> SIGSTOP",signal-meaning="Stop",frame={level="0",addr="
> 0x7f4bdf53e2d0",func="??",file="??",fullname="??",line="
> -1"},thread-id="1",stopped-threads="all"
> -
>
> In my project, I dont want to stop there.
> Where is a good point to investigate the code triggering SIGSTOP ?
>
>
> BR,
> Chunseok Lee
>
> --
> Where Do We come from? What Are We? Where Are We Going?
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
--
- Ilia
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb-mi stopped after '-target-select remote'
> On Oct 18, 2016, at 10:14 PM, Chunseok Lee via lldb-dev
> wrote:
>
> I have noticed that lldb-mi stopped after executing "-target-select remote".
> My execution step is like:
> -
> $ lldb-server g --platform=remote-linux "*:1234"
>
> $ lldb-mi
> (gdb)
> -file-exec-and-symbols /home/twoflower/a.out
> (gdb)
> -target-select remote localhost:1234
> .
> (gdb)
> *stopped,reason="signal-received",signal-name="SIGSTOP",signal-meaning="Stop",frame={level="0",addr="0x7f4bdf53e2d0",func="??",file="??",fullname="??",line="-1"},thread-id="1",stopped-threads="all"
> -
>
> In my project, I dont want to stop there.
> Where is a good point to investigate the code triggering SIGSTOP ?
I believe that many systems halt the process when you attach to it, so this is
normal. Just continue using normal debugger commands. This can all be done from
your IDE.
Greg
>
>
> BR,
> Chunseok Lee
>
> --
> Where Do We come from? What Are We? Where Are We Going?
> ___
> 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
[lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4
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
Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4
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 > 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
Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4
>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 > ___ 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
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 -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 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 ___ 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
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 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 > ___ 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
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. 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 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 >> > -- Tim ___ 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
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 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 > > > > > -- > Tim > ___ 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
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 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 < >> 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 >> >> >> >> >> -- >> Tim >> > -- Tim ___ 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
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 < > 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/mai
