[lldb-dev] [Bug 43625] DataExtractor::GetCStr may access extra byte out of bound when working with non-zero terminated string

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=43625

Raphael Isemann  changed:

   What|Removed |Added

   Assignee|lldb-dev@lists.llvm.org |teempe...@gmail.com
 Status|NEW |CONFIRMED
 CC||teempe...@gmail.com

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

Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: End-to-end testing

[Renato Golin via lldb-dev]

On Thu, 10 Oct 2019 at 10:56, Florian Hahn  wrote:
> Have you considered alternatives to checking the assembly for ensuring 
> vectorization or other transformations? For example, instead of checking the 
> assembly, we could check LLVM’s statistics or optimization remarks. If you 
> want to ensure a loop got vectorized, you could check the loop-vectorize 
> remarks, which should give you the position of the loop in the source and 
> vectorization/interleave factor used. There are few other things that could 
> go wrong later on that would prevent vector instruction selection, but I 
> think it should be sufficient to guard against most cases where we loose 
> vectorization and should be much more robust to unrelated changes. If there 
> are additional properties you want to ensure, they potentially could be added 
> to the remark as well.

We used to have lots of them, at least in the initial implementation
of the loop vectoriser (I know, many years ago).

The thread has enough points not to repeat here, but I guess the main
point is to make sure we don't duplicate tests, increasing CI cost
(especially on slower hardware).

I'd recommend trying to move any e2e tests into the test-suite and
make it easier to run, and leave specific tests only in the repo (to
guarantee independence of components).

The last thing we want is to create direct paths from front-ends to
back-ends and make LLVM IR transformation less flexible.

cheers,
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: End-to-end testing

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: llvm-dev  On Behalf Of David Greene
> via llvm-dev
> Sent: Wednesday, October 09, 2019 9:17 PM
> To: Mehdi AMINI 
> Cc: llvm-...@lists.llvm.org; cfe-...@lists.llvm.org; openmp-
> d...@lists.llvm.org; lldb-dev@lists.llvm.org
> Subject: Re: [llvm-dev] [cfe-dev] RFC: End-to-end testing
> 
> Mehdi AMINI via cfe-dev  writes:
> 
> > I don't think these particular tests are the most controversial though,
> and
> > it is really still fairly "focused" testing. I'm much more curious about
> > larger end-to-end scope: for instance since you mention debug info and
> > LLDB, what about a test that would verify that LLDB can print a
> particular
> > variable content from a test that would come as a source program for
> > instance. Such test are valuable in the absolute, it isn't clear to me
> that
> > we could in practice block any commit that would break such test though:
> > this is because a bug fix or an improvement in one of the pass may be
> > perfectly correct in isolation but make the test fail by exposing a bug
> > where we are already losing some debug info precision in a totally
> > unrelated part of the codebase.
> > I wonder how you see this managed in practice: would you gate any change
> on
> > InstCombine (or other mid-level pass) on not regressing any of the
> > debug-info quality test on any of the backend, and from any frontend
> (not
> > only clang)? Or worse: a middle-end change that would end-up with a
> > slightly different Dwarf construct on this particular test, which would
> > trip LLDB but not GDB (basically expose a bug in LLDB). Should we
> require
> > the contributor of inst-combine to debug LLDB and fix it first?
> 
> Good questions!  I think for situations like this I would tend toward
> allowing the change and the test would alert us that something else is
> wrong.  At that point it's probably a case-by-case decision.  Maybe we
> XFAIL the test.  Maybe the fix is easy enough that we just do it and the
> test starts passing again.  What's the policy for breaking current tests
> when the change itself is fine but exposes a problem elsewhere (adding
> an assert, for example)?

For debug info in particular, we already have the debuginfo-tests project,
which is separate because it requires executing the test program; this is
something the clang/llvm test suites specifically do NOT require.  There
is of course also the LLDB test suite, which I believe can be configured
to use the just-built clang to compile its test programs.

Regarding breakage policy, it's just like anything else: do what's needed
to make the bots happy.  What exactly that means will depend on the exact
situation.  I can cite a small patch that was held off for a ridiculously
long time, like around a year, because Chromium had some environmental
problem that they were slow to address.  That wasn't even an LLVM bot!
But eventually it got sorted out and our patch went in.

My point here is, that kind of thing happens already, adding a new e2e
test project won't inherently change any policy or how the community
responds to breakage.
--paulr

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

Re: [lldb-dev] test setup for windows -- makefiles

[Adrian McCarthy via lldb-dev]

I'm not sure this is entirely up to date, but I'd start here, especially
the Software section:

https://llvm.org/docs/GettingStartedVS.html

We get most of those unix-y tools on Windows via GnuWin32.  For LLDB
development, you almost certainly want a Python 3 rather than the
recommended 2.7.

There's also some LLDB-specific advice for setting up on Windows:

https://lldb.llvm.org/resources/build.html#windows

Feel free to ask more questions if those links are
confusing/wrong/out-of-date/incomplete/etc.



On Wed, Oct 9, 2019 at 5:12 PM Larry D'Anna via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi lldb-dev.
>
> Most of the tests build binaries to test with using Makefiles, and these
> Makefiles use all sorts of unix commands
> like sed and uname.And yet I see the build-bot is running `ninja-check
> lldb` on windows.
>
>
> I thought maybe if I installed MinGW that would have enough stuff in it to
> run the tests, but that doesn’t seem to be
> true.
>
> Does anyone have instructions for how to set up a windows test host for
> LLDB?   Or  a list of dependencies that
> should be installed?
>
> Thanks.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing

[Robinson, Paul via lldb-dev]

David Greene, will you be at the LLVM Dev Meeting? If so, could you sign
up for a Round Table session on this topic?  Obviously lots to discuss
and concerns to be addressed.

In particular I think there are two broad categories of tests that would
have to be segregated just by the nature of their requirements:

(1) Executable tests. These obviously require an execution platform; for
feasibility reasons this means host==target and the guarantee of having
a linker (possibly but not necessarily LLD) and a runtime (possibly but
not necessarily including libcxx).  Note that the LLDB tests and the 
debuginfo-tests project already have this kind of dependency, and in the
case of debuginfo-tests, this is exactly why it's a separate project.

(2) Non-executable tests.  These are near-identical in character to the
existing clang/llvm test suites and I'd expect lit to drive them.  The 
only material difference from the majority(*) of existing clang tests is 
that they are free to depend on LLVM features/passes.  The only difference 
from the majority of existing LLVM tests is that they have [Obj]{C,C++} as 
their input source language.
(*) I've encountered clang tests that I feel depend on too much within LLVM,
and it's common for new contributors to provide a C/C++ test that needs to 
be converted to a .ll test.  Some of them go in anyway.

More comments/notes below.

> -Original Message-
> From: lldb-dev  On Behalf Of David Greene
> via lldb-dev
> Sent: Wednesday, October 09, 2019 9:25 PM
> To: Philip Reames ; llvm-...@lists.llvm.org;
> cfe-...@lists.llvm.org; openmp-...@lists.llvm.org; lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing
> 
> Philip Reames via cfe-dev  writes:
> 
> > A challenge we already have - as in, I've broken these tests and had to
> > fix them - is that an end to end test which checks either IR or assembly
> > ends up being extraordinarily fragile.  Completely unrelated profitable
> > transforms create small differences which cause spurious test failures.
> > This is a very real issue today with the few end-to-end clang tests we
> > have, and I am extremely hesitant to expand those tests without giving
> > this workflow problem serious thought.  If we don't, this could bring
> > development on middle end transforms to a complete stop.  (Not kidding.)
> 
> Do you have a pointer to these tests?  We literally have tens of
> thousands of end-to-end tests downstream and while some are fragile, the
> vast majority are not.  A test that, for example, checks the entire
> generated asm for a match is indeed very fragile.  A test that checks
> whether a specific instruction/mnemonic was emitted is generally not, at
> least in my experience.  End-to-end tests require some care in
> construction.  I don't think update_llc_test_checks.py-type operation is
> desirable.

Sony likewise has a rather large corpus of end-to-end tests.  I expect any
vendor would.  When they break, we fix them or report/fix the compiler bug.
It has not been an intolerable burden on us, and I daresay if it were at
all feasible to put these upstream, it would not be an intolerable burden
on the community.  (It's not feasible because host!=target and we'd need
to provide test kits to the community and our remote-execution tools. We'd
rather just run them internally.)

Philip, what I'm actually hearing from your statement is along the lines,
"Our end-to-end tests are really fragile, therefore any end-to-end test 
will be fragile, and that will be an intolerable burden."

That's an understandable reaction, but I think the community literally
would not tolerate too-fragile tests.  Tests that are too fragile will 
be made more robust or removed.  This has been community practice for a 
long time.  There's even an entire category of "noisy bots" that certain 
people take care of and don't bother the rest of the community.  The 
LLVM Project as a whole would not tolerate a test suite that "could 
bring development ... to a complete stop" and I hope we can ease your
concerns.

More comments/notes/opinions below.

> 
> Still, you raise a valid point and I think present some good options
> below.
> 
> > A couple of approaches we could consider:
> >
> >  1. Simply restrict end to end tests to crash/assert cases.  (i.e. no
> > property of the generated code is checked, other than that it is
> > generated)  This isn't as restrictive as it sounds when combined
> > w/coverage guided fuzzer corpuses.
> 
> I would be pretty hesitant to do this but I'd like to hear more about
> how you see this working with coverage/fuzzing.

I think this is way too restrictive.

> 
> >  2. Auto-update all diffs, but report them to a human user for
> > inspection.  This ends up meaning that tests never "fail" per se,
> > but that individuals who have expressed interest in particular tests
> > get an automated notification and a chance to respond on list with a
> > reduced example.
> 
> T

Re: [lldb-dev] [Openmp-dev] GitHub Migration Schedule and Plans

[Tom Stellard via lldb-dev]

On 10/09/2019 10:16 PM, Tom Stellard via Openmp-dev wrote:
> Hi,
> 
> We're less than 2 weeks away from the developer meeting, so I wanted to
> give an update on the GitHub migration and what's (hopefully) going to
> happen during the developer meeting.
> 
> Everyone who has added their information to the github-usernames.txt
> file in SVN before today should have received an invite to become a 
> collaborator
> on the llvm-project repository.  If you did not receive an invite and think
> you should have, please contact me off-list.  I will continue to monitor the
> file for new updates and periodically send out new batches of invites.
> 

It seems like not everyone received email notifications of the invites
(it may depend on your settings).  You should be able to see your invite
if you go to https://github.com/llvm/llvm-project/invitations.

-Tom

> There is still some ongoing work to get the buildbots ready and the mailing 
> lists
> ready, but we are optimistic that the work will be done in time.
> 
> The team at GitHub has finished implementing the "Require Linear History"
> branch protection that we requested.  The feature is in beta and currently
> enabled in the llvm-project repository.  This means that we will have the
> option to commit directly via git, in addition to using the git-llvm script.
> A patch that updates git-llvm to push to git instead of svn can be found here:
> https://reviews.llvm.org/D67772.  You should be able to test it out on your
> own fork of the llvm-project repository.
> 
> The current plan is to begin the final migration steps on the evening (PDT)
> of October 21.  Here is what will happen:
> 
> 1. Make SVN read-only.
> 2. Turn-off the SVN->git update process.
> 3. Commit the new git-llvm script directly to github.
> 4. Grant all contributors write access to the repository.
> 5. Email lists announcing that the migration is complete.
> 
> Once the migration is complete, if you run into any issues, please file
> a bug, and mark it as a blocker for the github metabug PR39393.
> 
> If you have any questions or think I am missing something, please
> let me know.
> 
> Thanks,
> Tom
> ___
> Openmp-dev mailing list
> openmp-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
> 

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

Re: [lldb-dev] [cfe-dev] GitHub Migration Schedule and Plans

[Tom Stellard via lldb-dev]

On 10/09/2019 11:05 PM, Mehdi AMINI wrote:
> 
> 
> On Wed, Oct 9, 2019 at 10:16 PM Tom Stellard via cfe-dev 
> mailto:cfe-...@lists.llvm.org>> wrote:
> 
> Hi,
> 
> We're less than 2 weeks away from the developer meeting, so I wanted to
> give an update on the GitHub migration and what's (hopefully) going to
> happen during the developer meeting.
> 
> Everyone who has added their information to the github-usernames.txt
> file in SVN before today should have received an invite to become a 
> collaborator
> on the llvm-project repository.  If you did not receive an invite and 
> think
> you should have, please contact me off-list.  I will continue to monitor 
> the
> file for new updates and periodically send out new batches of invites.
> 
> There is still some ongoing work to get the buildbots ready and the 
> mailing lists
> ready, but we are optimistic that the work will be done in time.
> 
> The team at GitHub has finished implementing the "Require Linear History"
> branch protection that we requested.  The feature is in beta and currently
> enabled in the llvm-project repository.  This means that we will have the
> option to commit directly via git, in addition to using the git-llvm 
> script.
> A patch that updates git-llvm to push to git instead of svn can be found 
> here:
> https://reviews.llvm.org/D67772.  You should be able to test it out on 
> your
> own fork of the llvm-project repository.
> 
> The current plan is to begin the final migration steps on the evening 
> (PDT)
> of October 21.  Here is what will happen:
> 
> 1. Make SVN read-only.
> 2. Turn-off the SVN->git update process.
> 3. Commit the new git-llvm script directly to github.
> 4. Grant all contributors write access to the repository.
> 
> 
> Is the repo configured to forbid contributors to create new branches? I'm 
> worried about the "jungle" it can become quickly if we leave open the 
> possibility to create branches "at will" in the repo, I rather leave this to 
> maintainers.
> 

I haven't been able to find a way to restrict branch creation for committers,
I'm not sure if this is even possible.

We could try to enforce this rule in the git-llvm script, but this would
mean making use of the script mandatory, which was our original plan, but
that was based on the assumption that the "Require Linear History"
protection would not be ready in time.

Generally, would it be better if we kept use of the script mandatory so that 
we can handle this and other potential restrictions in the future?

- Tom
>  
> 
> 5. Email lists announcing that the migration is complete.
> 
> Once the migration is complete, if you run into any issues, please file
> a bug, and mark it as a blocker for the github metabug PR39393.
> 
> If you have any questions or think I am missing something, please
> let me know.
> 
> 
> This is fantastic! Thank you so much for doing this work Tom :)
> 
> -- 
> Mehdi
> 
>  

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

Re: [lldb-dev] [cfe-dev] GitHub Migration Schedule and Plans

[Martin Storsjö via lldb-dev]

On Thu, 10 Oct 2019, Tom Stellard via cfe-dev wrote:


On 10/09/2019 11:05 PM, Mehdi AMINI wrote:



On Wed, Oct 9, 2019 at 10:16 PM Tom Stellard via cfe-dev mailto:cfe-...@lists.llvm.org>> wrote:

Hi,

We're less than 2 weeks away from the developer meeting, so I wanted to
give an update on the GitHub migration and what's (hopefully) going to
happen during the developer meeting.

Everyone who has added their information to the github-usernames.txt
file in SVN before today should have received an invite to become a 
collaborator
on the llvm-project repository.  If you did not receive an invite and think
you should have, please contact me off-list.  I will continue to monitor the
file for new updates and periodically send out new batches of invites.

There is still some ongoing work to get the buildbots ready and the mailing 
lists
ready, but we are optimistic that the work will be done in time.

The team at GitHub has finished implementing the "Require Linear History"
branch protection that we requested.  The feature is in beta and currently
enabled in the llvm-project repository.  This means that we will have the
option to commit directly via git, in addition to using the git-llvm script.
A patch that updates git-llvm to push to git instead of svn can be found 
here:
https://reviews.llvm.org/D67772.  You should be able to test it out on your
own fork of the llvm-project repository.

The current plan is to begin the final migration steps on the evening (PDT)
of October 21.  Here is what will happen:

1. Make SVN read-only.
2. Turn-off the SVN->git update process.
3. Commit the new git-llvm script directly to github.
4. Grant all contributors write access to the repository.


Is the repo configured to forbid contributors to create new branches? I'm worried about the 
"jungle" it can become quickly if we leave open the possibility to create branches 
"at will" in the repo, I rather leave this to maintainers.



I haven't been able to find a way to restrict branch creation for committers,
I'm not sure if this is even possible.

We could try to enforce this rule in the git-llvm script, but this would
mean making use of the script mandatory, which was our original plan, but
that was based on the assumption that the "Require Linear History"
protection would not be ready in time.

Generally, would it be better if we kept use of the script mandatory so that 
we can handle this and other potential restrictions in the future?


Personally, I'd prefer to avoid requiring a custom tool for pushing 
commits, if possible.


As for creating undesired branches; contrary to accidentally pushing merge 
commits on the master branch, any accidentally created branch should be 
possible to remove without any permanent traces left behind (especially as 
it doesn't affect the master branch). So for that purpose alone, I'd vote 
for not requiring git-llvm for pushing.


Btw, out of curiousity, what mechanism does GitHub offer for verifying 
that the push actually comes from git-llvm? (I'm sorry if this part was 
discussed elsewhere, but I don't remember seeing it discussed lately.)


// Martin

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

Re: [lldb-dev] [cfe-dev] GitHub Migration Schedule and Plans

[Tom Stellard via lldb-dev]

On 10/10/2019 11:40 AM, Mehdi AMINI wrote:
> 
> 
> On Thu, Oct 10, 2019 at 10:59 AM Tom Stellard  > wrote:
> 
> On 10/09/2019 11:05 PM, Mehdi AMINI wrote:
> >
> >
> > On Wed, Oct 9, 2019 at 10:16 PM Tom Stellard via cfe-dev 
> mailto:cfe-...@lists.llvm.org> 
> >> wrote:
> >
> > Hi,
> >
> > We're less than 2 weeks away from the developer meeting, so I 
> wanted to
> > give an update on the GitHub migration and what's (hopefully) going 
> to
> > happen during the developer meeting.
> >
> > Everyone who has added their information to the github-usernames.txt
> > file in SVN before today should have received an invite to become a 
> collaborator
> > on the llvm-project repository.  If you did not receive an invite 
> and think
> > you should have, please contact me off-list.  I will continue to 
> monitor the
> > file for new updates and periodically send out new batches of 
> invites.
> >
> > There is still some ongoing work to get the buildbots ready and the 
> mailing lists
> > ready, but we are optimistic that the work will be done in time.
> >
> > The team at GitHub has finished implementing the "Require Linear 
> History"
> > branch protection that we requested.  The feature is in beta and 
> currently
> > enabled in the llvm-project repository.  This means that we will 
> have the
> > option to commit directly via git, in addition to using the 
> git-llvm script.
> > A patch that updates git-llvm to push to git instead of svn can be 
> found here:
> > https://reviews.llvm.org/D67772.  You should be able to test it out 
> on your
> > own fork of the llvm-project repository.
> >
> > The current plan is to begin the final migration steps on the 
> evening (PDT)
> > of October 21.  Here is what will happen:
> >
> > 1. Make SVN read-only.
> > 2. Turn-off the SVN->git update process.
> > 3. Commit the new git-llvm script directly to github.
> > 4. Grant all contributors write access to the repository.
> >
> >
> > Is the repo configured to forbid contributors to create new branches? 
> I'm worried about the "jungle" it can become quickly if we leave open the 
> possibility to create branches "at will" in the repo, I rather leave this to 
> maintainers.
> >
> 
> I haven't been able to find a way to restrict branch creation for 
> committers,
> I'm not sure if this is even possible.
> 
> 
> I think you can just go to the branch settings, add a new branch protection 
> rule, match on everything but master, and check "Restrict who can push to 
> matching branches".
> 

I tried this, and the branch protections only come into effect after a branch
has been creating, so this doesn't prevent new branches.  It's actually worse
than doing nothing, because once the branch is created the branch protection
prevents you from deleting it.

-Tom

>  
> 
> We could try to enforce this rule in the git-llvm script, but this would
> mean making use of the script mandatory, which was our original plan, but
> that was based on the assumption that the "Require Linear History"
> protection would not be ready in time.
> 
> Generally, would it be better if we kept use of the script mandatory so 
> that
> we can handle this and other potential restrictions in the future?
> 
> - Tom
> > 
> >
> > 5. Email lists announcing that the migration is complete.
> >
> > Once the migration is complete, if you run into any issues, please 
> file
> > a bug, and mark it as a blocker for the github metabug PR39393.
> >
> > If you have any questions or think I am missing something, please
> > let me know.
> >
> >
> > This is fantastic! Thank you so much for doing this work Tom :)
> >
> > --
> > Mehdi
> >
> > 
> 

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

Re: [lldb-dev] [cfe-dev] GitHub Migration Schedule and Plans

[Martin Storsjö via lldb-dev]

On Thu, 10 Oct 2019, Mehdi AMINI wrote:




On Thu, Oct 10, 2019 at 12:02 PM Martin Storsjö  wrote:
  On Thu, 10 Oct 2019, Tom Stellard via cfe-dev wrote:

  > On 10/09/2019 11:05 PM, Mehdi AMINI wrote:
  >>
  >>
  >> On Wed, Oct 9, 2019 at 10:16 PM Tom Stellard via cfe-dev
  mailto:cfe-...@lists.llvm.org>> wrote:
  >
  > I haven't been able to find a way to restrict branch creation
  for committers,
  > I'm not sure if this is even possible.
  >
  > We could try to enforce this rule in the git-llvm script, but
  this would
  > mean making use of the script mandatory, which was our
  original plan, but
  > that was based on the assumption that the "Require Linear
  History"
  > protection would not be ready in time.
  >
  > Generally, would it be better if we kept use of the script
  mandatory so that
  > we can handle this and other potential restrictions in the
  future?

  Personally, I'd prefer to avoid requiring a custom tool for
  pushing
  commits, if possible.

  As for creating undesired branches; contrary to accidentally
  pushing merge
  commits on the master branch, any accidentally created branch
  should be
  possible to remove without any permanent traces left behind
  (especially as
  it doesn't affect the master branch). So for that purpose alone,
  I'd vote
  for not requiring git-llvm for pushing.


The original reason for the tool is about linear history (contrary to
branches, this can't be undone).


Yes, I see (or saw) the reason for the tool if a linear history couldn't 
be guaranteed otherwise, but I'm more hesitant if the only current purpose 
is preventing branch creation.



  Btw, out of curiousity, what mechanism does GitHub offer for
  verifying
  that the push actually comes from git-llvm? (I'm sorry if this
  part was
  discussed elsewhere, but I don't remember seeing it discussed
  lately.)


I mentioned it on LLVM-dev a couple of times a while back (here for example:
http://lists.llvm.org/pipermail/llvm-dev/2019-February/129896.html )

But apparently the concrete implementation was discussed on cfe-dev@ only,
so here are the details:
http://lists.llvm.org/pipermail/cfe-dev/2019-April/062063.html 


Ok, thanks for the references! That's a rather interesting feature they 
have.


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

Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: End-to-end testing

[David Greene via lldb-dev]

Florian Hahn via llvm-dev  writes:

>> - Performance varies from implementation to implementation.  It is
>>  difficult to keep tests up-to-date for all possible targets and
>>  subtargets.
>
> Could you expand a bit more what you mean here? Are you concerned
> about having to run the performance tests on different kinds of
> hardware? In what way do the existing benchmarks require keeping
> up-to-date?

We have to support many different systems and those systems are always
changing (new processors, new BIOS, new OS, etc.).  Performance can vary
widely day to day from factors completely outside the compiler's
control.  As the performance changes you have to keep updating the tests
to expect the new performance numbers.  Relying on performance
measurements to ensure something like vectorization is happening just
isn't reliable in our experience.

> With tests checking ASM, wouldn’t we end up with lots of checks for
> various targets/subtargets that we need to keep up to date?

Yes, that's true.  But the only thing that changes the asm generated is
the compiler.

> Just considering AArch64 as an example, people might want to check the
> ASM for different architecture versions and different vector
> extensions and different vendors might want to make sure that the ASM
> on their specific cores does not regress.

Absolutely.  We do a lot of that sort of thing downstream.

>> - Partially as a result, but also for other reasons, performance tests
>>  tend to be complicated, either in code size or in the numerous code
>>  paths tested.  This makes such tests hard to debug when there is a
>>  regression.
>
> I am not sure they have to. Have you considered adding the small test
> functions/loops as micro-benchmarks using the existing google
> benchmark infrastructure in test-suite?

We have tried nightly performance runs using LNT/test-suite and have
found it to be very unreliable, especially the microbenchmarks.

> I think that might be able to address the points here relatively
> adequately. The separate micro benchmarks would be relatively small
> and we should be able to track down regressions in a similar fashion
> as if it would be a stand-alone file we compile and then analyze the
> ASM. Plus, we can easily run it and verify the performance on actual
> hardware.

A few of my colleagues really struggled to get consistent results out of
LNT.  They asked for help and discussed with a few upstream folks, but
in the end were not able to get something reliable working.  I've talked
to a couple of other people off-list and they've had similar
experiences.  It would be great if we have a reliable performance suite.
Please tell us how to get it working!  :)

But even then, I still maintain there is a place for the kind of
end-to-end testing I describe.  Performance testing would complement it.
Neither is a replacement for the other.

>> - Performance tests don't focus on the why/how of vectorization.  They
>>  just check, "did it run fast enough?"  Maybe the test ran fast enough
>>  for some other reason but we still lost desired vectorization and
>>  could have run even faster.
>> 
>
> If you would add a new micro-benchmark, you could check that it
> produces the desired result when adding it. The runtime-tracking
> should cover cases where we lost optimizations. I guess if the
> benchmarks are too big, additional optimizations in one part could
> hide lost optimizations somewhere else. But I would assume this to be
> relatively unlikely, as long as the benchmarks are isolated.

Even then I have seen small performance tests vary widely in performance
due to system issues (see above).  Again, there is a place for them but
they are not sufficient.

> Also, checking the assembly for vector code does also not guarantee
> that the vector code will be actually executed. So for example by just
> checking the assembly for certain vector instructions, we might miss
> that we regressed performance, because we messed up the runtime checks
> guarding the vector loop.

Oh absolutely.  Presumably such checks would be included in the test or
would be checked by a different test.  As always, tests have to be
constructed intelligently.  :)

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

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing

[David Greene via lldb-dev]

Florian Hahn via cfe-dev  writes:

> Have you considered alternatives to checking the assembly for ensuring
> vectorization or other transformations? For example, instead of
> checking the assembly, we could check LLVM’s statistics or
> optimization remarks.

Yes, absolutely.  We have tests that do things like that.  I don't want
to focus on the asm bit, that's just one type of test.  The larger issue
is end-to-end tests that ensure the compiler and other tools are working
correctly, be it from checking messages, statistics, asm or something
else.

> This idea of leveraging statistics and optimization remarks to track
> the impact of changes on overall optimization results is nothing new
> and I think several people already discussed it in various forms. For
> regular benchmark runs, in addition to tracking the existing
> benchmarks, we could also track selected optimization remarks
> (e.g. loop-vectorize, but not necessarily noisy ones like gvn) and
> statistics. Comparing those run-to-run could potentially highlight new
> end-to-end issues on a much larger scale, across all existing
> benchmarks integrated in test-suite. We might be able to detect loss
> in vectorization pro-actively, instead of requiring someone to file a
> bug report and then we add an isolated test after the fact.

That's an interesting idea!  I would love to get more use out of
test-suite.

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

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing

[David Greene via lldb-dev]

Renato Golin via cfe-dev  writes:

> I'd recommend trying to move any e2e tests into the test-suite and
> make it easier to run, and leave specific tests only in the repo (to
> guarantee independence of components).

That would be a shame.  Where is test-suite run right now?  Are there
bots?  How are regressions reported?

> The last thing we want is to create direct paths from front-ends to
> back-ends and make LLVM IR transformation less flexible.

I'm not sure I follow.  Can you explain this a bit?

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

[lldb-dev] does vFile:Open actually work?

[Larry D'Anna via lldb-dev]

The comments in File.h say:

  // NB this enum is used in the lldb platform gdb-remote packet
  // vFile:open: and existing values cannot be modified.
  enum OpenOptions {
eOpenOptionRead = (1u << 0),  // Open file for reading
eOpenOptionWrite = (1u << 1), // Open file for writing
eOpenOptionAppend =
(1u << 2), // Don't truncate file when opening, append to end of file

And In GDBRemoteCommunicationServerCommon.cpp it says:

  uint32_t flags = packet.GetHexMaxU32(false, 0);
  if (packet.GetChar() == ',') {
mode_t mode = packet.GetHexMaxU32(false, 0600);
FileSpec path_spec(path);
FileSystem::Instance().Resolve(path_spec);
// Do not close fd.
auto file = FileSystem::Instance().Open(path_spec, flags, mode, false);


But in the GDB documentation it says:

@node Open Flags
@unnumberedsubsubsec Open Flags
@cindex open flags, in file-i/o protocol

All values are given in hexadecimal representation.

@smallexample
  O_RDONLY0x0
  O_WRONLY0x1
  O_RDWR  0x2
  O_APPEND0x8
  O_CREAT   0x200
  O_TRUNC   0x400
  O_EXCL0x800
@end smallexample


Does vFile:Open actually work?  Are there any tests that cover it?

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

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing

[Renato Golin via lldb-dev]

On Thu, 10 Oct 2019 at 22:26, David Greene  wrote:
> That would be a shame.  Where is test-suite run right now?  Are there
> bots?  How are regressions reported?

There is no shame in making the test-suite better.

We do have bots running them in full CI for multiple targets, yes.
Regressions are reported and fixed. The benchmarks are also followed
by a smaller crowd and regression on those are also fixed (but
slower).

I'm not proposing to move e2e off to a dark corner, I'm proposing to
have a scaled testing strategy that can ramp up and down as needed,
without upsetting the delicate CI and developer balance.

Sure, e2e tests are important, but they need to catch bugs that the
other tests don't catch, not being our front-line safety net.

We planned doing incremental testing with buildbots for years and
Apple has done something like that in their GreenBots. We have talked
to move that upstream, but time spent in testing is really really
scant.

A few years back there was a big effort to clean up the LIT tests from
duplicates and speed up inefficient code, and a lot of tests are
removed. If we just add the e2e today and they never catch anything
relevant, they'll be the next candidates to go.

The delta that e2e can test is really important, but really small and
fairly rare. So running it less frequent (every few dozen commits)
will most likely be enough for anything we can possibly respond to
upstream.

My main point is that we need to be realistic with what we can do
upstream, which is very different from which a big company can do
downstream.

Past experiences have, over and over, shown us that new shiny CI toys
get rusty, noisy, and dumped.

We want to have the tests, in a place anyone can test, that the bots
*will* test periodically, and that don't annoy developers often enough
to be a target.

In a nutshell:
 * We still need src2src tests, to ensure connection points (mainly
IR) are canonical and generic, avoiding hidden contracts
 * We want the end2end tests to *add* coverage, not overlap with or
replace existing tests
 * We don't want those tests to become a burden to developers by
breaking on unrelated changes and making bots red for obscure reasons
 * We don't want them to be a burden to our CI efforts, slowing down
regular LIT testing and becoming a target for removal

The orders of magnitude for number of commits we want to run tests are:
 * LIT base, linker, compiler-RT, etc: ~1
 * Test-suite correctness, end-2-end: ~10
 * Multi-stage build, benchmarks: ~100

We already have that ratio (somewhat) with buildbots, so it should be
simple to add e2e to the test suite at the right scale.

> > The last thing we want is to create direct paths from front-ends to
> > back-ends and make LLVM IR transformation less flexible.
>
> I'm not sure I follow.  Can you explain this a bit?

Right, I had written a long paragraph about it but deleted in the
final version of my email. :)

The main point is that we want to avoid hidden contracts between the
front-end and the back-end.

We want to make sure all front-ends can produce canonical IR, and that
the middle-end can optimise the IR and that the back-end can lower
that to asm in a way that runs correctly on the target. As we have
multiple back-ends and are soon to have a second official front-end,
we want to make sure we have good coverage on the multi-step tests
(AST to IR, IR to asm, etc).

If we add e2e tests that are not covered by piece-wise tests, we risk
losing that clarity.

I think e2e tests have to expose more complex issues, like front-end
changes, pass manager order, optimisation levels, linking issues, etc.
They can check for asm, run on the target, or both. In the test-suite
we have more budget to do a more complete job at it than in LIT
check-all.

Hope this helps.

cheers,
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLDB finish_swig and Python module installation broken for multi-configuration generators

[Ted Woodward via lldb-dev]

Starting in r372835 (Fix installing Python modules on systems using /usr/lib), 
the finish_swig and installation steps using multi-configuration generators 
(like Visual Studio or XCode) are broken.

The problem is the symlink and install steps look for liblldb and site-packages 
the wrong directories.

For the symlink, I get this output:
 Making symlink from ..\..\..\bin\liblldb.dll to 
i:\obj\lib\site-packages\lldb\_lldb.pyd
...
 WindowsError: [Error 2] The system cannot find the file specified: 
'..\\..\\..\\bin\\liblldb.dll'

Because the cwd is I:\obj\Lib\site-packages\lldb, not the correct 
I:\obj\Release\Lib\site-packages\lldb. liblldb.dll is in i:\obj\Release\bin, 
not i:\obj\bin. Also, the link itself should be in i:\obj\Release\lib, not 
i:\obj\lib.

The problem is the cmake code went from using LLVM_LIBRARY_OUTPUT_INTDIR to 
CMAKE_BINARY_DIR. CMAKE_BINARY_DIR is not complete for multi-configuration 
generators - you need to specify the configuration as well.

To fix it, in lldb/CMakeLists.txt change
if(LLDB_BUILD_FRAMEWORK)
  set(lldb_python_build_path 
"${liblldb_build_dir}/LLDB.framework/Resources/Python/lldb")
else()
  set(lldb_python_build_path 
"${CMAKE_BINARY_DIR}/${LLDB_PYTHON_RELATIVE_PATH}/lldb")
endif()

to:
if(LLDB_BUILD_FRAMEWORK)
  set(lldb_python_build_path 
"${liblldb_build_dir}/LLDB.framework/Resources/Python/lldb")
else()
  if(CMAKE_CFG_INTDIR)
   # use CMAKE_BUILD_TYPE here because CMAKE_CFG_INTDIR is ${Configuration}
# using Visual Studio, which won't work in cmake_install.cmake
# because it is a VS variable, not a cmake variable
install(DIRECTORY 
${CMAKE_BINARY_DIR}/${CMAKE_BUILD_TYPE}/${LLDB_PYTHON_RELATIVE_PATH}/
DESTINATION ${LLDB_PYTHON_RELATIVE_PATH}
COMPONENT lldb-scripts)
  else()
install(DIRECTORY ${CMAKE_BINARY_DIR}/${LLDB_PYTHON_RELATIVE_PATH}/
DESTINATION ${LLDB_PYTHON_RELATIVE_PATH}
COMPONENT lldb-scripts)
  endif()
endif()


In the install step we have a similar failure. The install in 
lldb/CMakeLists.txt again uses CMAKE_BINARY_DIR. To fix it, change:
  install(DIRECTORY ${CMAKE_BINARY_DIR}/${LLDB_PYTHON_RELATIVE_PATH}/
  DESTINATION ${LLDB_PYTHON_RELATIVE_PATH}
  COMPONENT lldb-scripts)
to:
  if(CMAKE_CFG_INTDIR)
install(DIRECTORY 
${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${LLDB_PYTHON_RELATIVE_PATH}/
DESTINATION ${LLDB_PYTHON_RELATIVE_PATH}
COMPONENT lldb-scripts)
  else()
install(DIRECTORY ${CMAKE_BINARY_DIR}/${LLDB_PYTHON_RELATIVE_PATH}/
DESTINATION ${LLDB_PYTHON_RELATIVE_PATH}
COMPONENT lldb-scripts)
  endif()


Michal, please try this and see if it still works for the issue you fixed in 
r372835.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub Migration Schedule and Plans

[Tom Stellard via lldb-dev]

On 10/10/2019 03:50 PM, Mehdi AMINI wrote:
> 
> 
> On Thu, Oct 10, 2019 at 1:14 PM Jordan Rupprecht  > wrote:
> 
> 
> 
> On Thu, Oct 10, 2019 at 12:29 PM Tom Stellard via llvm-dev 
> mailto:llvm-...@lists.llvm.org>> wrote:
> 
> On 10/10/2019 11:40 AM, Mehdi AMINI wrote:
> >
> >
> > On Thu, Oct 10, 2019 at 10:59 AM Tom Stellard    >> wrote:
> >
> > On 10/09/2019 11:05 PM, Mehdi AMINI wrote:
> > >
> > >
> > > On Wed, Oct 9, 2019 at 10:16 PM Tom Stellard via cfe-dev 
> mailto:cfe-...@lists.llvm.org> 
> > 
>  
>  > >
> > > Hi,
> > >
> > > We're less than 2 weeks away from the developer meeting, 
> so I wanted to
> > > give an update on the GitHub migration and what's 
> (hopefully) going to
> > > happen during the developer meeting.
> > >
> > > Everyone who has added their information to the 
> github-usernames.txt
> > > file in SVN before today should have received an invite 
> to become a collaborator
> > > on the llvm-project repository.  If you did not receive 
> an invite and think
> > > you should have, please contact me off-list.  I will 
> continue to monitor the
> > > file for new updates and periodically send out new 
> batches of invites.
> > >
> > > There is still some ongoing work to get the buildbots 
> ready and the mailing lists
> > > ready, but we are optimistic that the work will be done 
> in time.
> > >
> > > The team at GitHub has finished implementing the "Require 
> Linear History"
> > > branch protection that we requested.  The feature is in 
> beta and currently
> > > enabled in the llvm-project repository.  This means that 
> we will have the
> > > option to commit directly via git, in addition to using 
> the git-llvm script.
> > > A patch that updates git-llvm to push to git instead of 
> svn can be found here:
> > > https://reviews.llvm.org/D67772.  You should be able to 
> test it out on your
> > > own fork of the llvm-project repository.
> > >
> > > The current plan is to begin the final migration steps on 
> the evening (PDT)
> > > of October 21.  Here is what will happen:
> > >
> > > 1. Make SVN read-only.
> > > 2. Turn-off the SVN->git update process.
> > > 3. Commit the new git-llvm script directly to github.
> > > 4. Grant all contributors write access to the repository.
> > >
> > >
> > > Is the repo configured to forbid contributors to create new 
> branches? I'm worried about the "jungle" it can become quickly if we leave 
> open the possibility to create branches "at will" in the repo, I rather leave 
> this to maintainers.
> > >
> >
> > I haven't been able to find a way to restrict branch creation 
> for committers,
> > I'm not sure if this is even possible.
> >
> >
> > I think you can just go to the branch settings, add a new branch 
> protection rule, match on everything but master, and check "Restrict who can 
> push to matching branches".
> >
> 
> I tried this, and the branch protections only come into effect after 
> a branch
> has been creating, so this doesn't prevent new branches.  It's 
> actually worse
> than doing nothing, because once the branch is created the branch 
> protection
> prevents you from deleting it.
> 
> 
> Ah, interesting :)
> Since for now `git-llvm` is necessary to push to the repo, I guess creating a 
> branch won't even really be possible? So when adding the support for branch 
> creation to `git-llvm` we could print a disclaimer about it or something?
> 

With my latest changes in https://reviews.llvm.org/D67772 it is actually 
possible
to create a new branch with git-llvm, so we could print a disclaimer or block 
this,
however we still can't stop people from creating a new branch using the
normal git command.

-Tom

> 
> 
> -Tom
> 
> 
> FWIW, we're interested in periodically (weekly) tagging 
> well-tested/stable revisions, but via a branch instead of just a tag so we 
> can include which cherrypicks (e.g. reverts or fixes) are needed. We do this 
> with the current svn repo so we'd just be porting existing functionality to 
> gi

Re: [lldb-dev] does vFile:Open actually work?

[Jason Molenda via lldb-dev]

Yeah, this is a bug in lldb's implementation of vFile:open.  lldb talks to 
lldb-server (in platform mode) so it will work with itself, but it will not 
interoperate with any other implementations.  That's the down side to having 
the client and server literally built from the same sources. :) 


I have a small self-contained platform implementation I wrote locally from the 
specification, and I stumbled across the bug last winter.  We'll need to add a 
packet so lldb can request standards-correct vFile:open: behavior, and fall 
back to its original implementation if it that is not understood for a while so 
we interoperate with existing platforms in the wild.

A similar type of bug is lldb's incorrect implementation of the A packet, see 
https://bugs.llvm.org/show_bug.cgi?id=42471 - Spencer had the good suggestion 
of creating a protocol fixes packet to query for these so additional ones can 
be added in the future, he suggested:


> Request: "qProtocolFixes:fix;…" where each 'fix' is one of the following 
> strings:
>   - "GDBFlagsInvFileOpen"
>   - "GDBBaseInAPacket"
>   - ...
> Unknown strings are acceptable, but ignored. If a fix  string is not present, 
> it is assumed that that fix is not present.
> 
> Response: "fix;…", same definition as 'fix' above.


I have a little TODO on myself to do this ().



J



> On Oct 10, 2019, at 2:39 PM, Larry D'Anna via lldb-dev 
>  wrote:
> 
> The comments in File.h say:
> 
>   // NB this enum is used in the lldb platform gdb-remote packet
>   // vFile:open: and existing values cannot be modified.
>   enum OpenOptions {
> eOpenOptionRead = (1u << 0),  // Open file for reading
> eOpenOptionWrite = (1u << 1), // Open file for writing
> eOpenOptionAppend =
> (1u << 2), // Don't truncate file when opening, append to end of file
> 
> And In GDBRemoteCommunicationServerCommon.cpp it says:
> 
>   uint32_t flags = packet.GetHexMaxU32(false, 0);
>   if (packet.GetChar() == ',') {
> mode_t mode = packet.GetHexMaxU32(false, 0600);
> FileSpec path_spec(path);
> FileSystem::Instance().Resolve(path_spec);
> // Do not close fd.
> auto file = FileSystem::Instance().Open(path_spec, flags, mode, 
> false);
> 
> 
> But in the GDB documentation it says:
> 
> @node Open Flags
> @unnumberedsubsubsec Open Flags
> @cindex open flags, in file-i/o protocol
> 
> All values are given in hexadecimal representation.
> 
> @smallexample
>   O_RDONLY0x0
>   O_WRONLY0x1
>   O_RDWR  0x2
>   O_APPEND0x8
>   O_CREAT   0x200
>   O_TRUNC   0x400
>   O_EXCL0x800
> @end smallexample
> 
> 
> Does vFile:Open actually work?  Are there any tests that cover it?
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

Re: [lldb-dev] LLDB finish_swig and Python module installation broken for multi-configuration generators

[Michał Górny via lldb-dev]

Dnia October 10, 2019 11:11:20 PM UTC, Ted Woodward  
napisał(a):
>Starting in r372835 (Fix installing Python modules on systems using
>/usr/lib), the finish_swig and installation steps using
>multi-configuration generators (like Visual Studio or XCode) are
>broken.
>
>The problem is the symlink and install steps look for liblldb and
>site-packages the wrong directories.
>
>For the symlink, I get this output:
>Making symlink from ..\..\..\bin\liblldb.dll to
>i:\obj\lib\site-packages\lldb\_lldb.pyd
>...
>WindowsError: [Error 2] The system cannot find the file specified:
>'..\\..\\..\\bin\\liblldb.dll'
>
>Because the cwd is I:\obj\Lib\site-packages\lldb, not the correct
>I:\obj\Release\Lib\site-packages\lldb. liblldb.dll is in
>i:\obj\Release\bin, not i:\obj\bin. Also, the link itself should be in
>i:\obj\Release\lib, not i:\obj\lib.
>
>The problem is the cmake code went from using
>LLVM_LIBRARY_OUTPUT_INTDIR to CMAKE_BINARY_DIR. CMAKE_BINARY_DIR is not
>complete for multi-configuration generators - you need to specify the
>configuration as well.
>
>To fix it, in lldb/CMakeLists.txt change
>if(LLDB_BUILD_FRAMEWORK)
>set(lldb_python_build_path
>"${liblldb_build_dir}/LLDB.framework/Resources/Python/lldb")
>else()
>set(lldb_python_build_path
>"${CMAKE_BINARY_DIR}/${LLDB_PYTHON_RELATIVE_PATH}/lldb")
>endif()
>
>to:
>if(LLDB_BUILD_FRAMEWORK)
>set(lldb_python_build_path
>"${liblldb_build_dir}/LLDB.framework/Resources/Python/lldb")
>else()
>  if(CMAKE_CFG_INTDIR)

Hm, can't intdir be used in regular builds as well? That'd simplify things.

># use CMAKE_BUILD_TYPE here because CMAKE_CFG_INTDIR is
>${Configuration}
># using Visual Studio, which won't work in cmake_install.cmake
># because it is a VS variable, not a cmake variable
>install(DIRECTORY
>${CMAKE_BINARY_DIR}/${CMAKE_BUILD_TYPE}/${LLDB_PYTHON_RELATIVE_PATH}/
>DESTINATION ${LLDB_PYTHON_RELATIVE_PATH}
>COMPONENT lldb-scripts)
>  else()
>install(DIRECTORY ${CMAKE_BINARY_DIR}/${LLDB_PYTHON_RELATIVE_PATH}/
>DESTINATION ${LLDB_PYTHON_RELATIVE_PATH}
>COMPONENT lldb-scripts)
>  endif()
>endif()
>
>
>In the install step we have a similar failure. The install in
>lldb/CMakeLists.txt again uses CMAKE_BINARY_DIR. To fix it, change:
>install(DIRECTORY ${CMAKE_BINARY_DIR}/${LLDB_PYTHON_RELATIVE_PATH}/
>  DESTINATION ${LLDB_PYTHON_RELATIVE_PATH}
>  COMPONENT lldb-scripts)
>to:
>  if(CMAKE_CFG_INTDIR)
>install(DIRECTORY
>${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${LLDB_PYTHON_RELATIVE_PATH}/
>DESTINATION ${LLDB_PYTHON_RELATIVE_PATH}
>COMPONENT lldb-scripts)
>  else()
>install(DIRECTORY ${CMAKE_BINARY_DIR}/${LLDB_PYTHON_RELATIVE_PATH}/
>DESTINATION ${LLDB_PYTHON_RELATIVE_PATH}
>COMPONENT lldb-scripts)
>  endif()
>
>
>Michal, please try this and see if it still works for the issue you
>fixed in r372835.

Thanks for the report. I should be able to test it in 7-8 hours.


--
Best regards, 
Michał Górny
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev