Re: [lldb-dev] [cfe-dev] [llvm-dev] Should we stop supporting building with Visual Studio?

[Chris Bieneman via lldb-dev]

I don't personally use the Xcode generator, but I know lots of people who do. 
The Xcode generator can generate a working Xcode project with an accurate clang 
index. One of the challenges to get that working though is that the project 
actually has to be able to build at least through intrinsics_gen, otherwise 
there are headers missing and the indexing falls over. I assume Visual Studio's 
intellisense also requires building through header generation for its indexing 
to work correctly.

Similar to MSBuild, Xcodebuild is *way* slower at building LLVM than ninja, so 
I think many Xcode users are already using a workflow similar to what Zachary 
described in his initial email, but I know people also run the test targets 
from Xcode.

Since the benefit of dropping support for building/testing with Visual studio 
would basically be moot without also dropping support for building/testing with 
Xcode I'm really not in favor of this.

I do think that the VS native CMake integration is promising, but it has a long 
way to come before it will really replace the native project generator. I've 
been using it when I use Windows (which admittedly isn't very often), and have 
found it to build well, but the UI is unwieldy, and it has problems with the 
number of build targets that LLVM's ninja build produces.

-Chris


> On Oct 10, 2018, at 9:40 AM, Danila Malyutin via cfe-dev 
>  wrote:
> 
> Have anyone had any experience with VS native CMake integration? You don’t 
> need to employ all the described hacks when you can just trigger Ninja build 
> from VS itself. I’ve used CMake + Ninja from VS on a couple smaller projects 
> without any problems. It was very smooth. But it might not be the case for 
> something as big and complicated as LLVM. I remember trying to use CMake 
> project about a year ago but in the end I’ve decided to stick with .sln . I 
> don’t recall whether there were some show stopping bugs, if it was generally 
> worse experience or something else. Also, the situation has probably changed 
> for the better since then. If not, perhaps that’s something LLVM could 
> improve from its side.
>  
> From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of Nicolas 
> Capens via llvm-dev
> Sent: Wednesday, October 10, 2018 17:16
> To: ztur...@google.com
> Cc: llvm-...@lists.llvm.org; cfe-...@lists.llvm.org; lldb-dev@lists.llvm.org
> Subject: Re: [llvm-dev] Should we stop supporting building with Visual Studio?
>  
> Hi Zachary,
>  
> We use LLVM JIT in SwiftShader, which is used by Google Chrome and Android 
> (Emulator). Most development takes place in Visual Studio, where it builds as 
> part of the rest of the SwiftShader solution. So we care about LLVM source 
> files compiling successfully within Visual Studio.
>  
> Would it be reasonable to at least ensure that major releases (7.0, 8.0, 
> etc.) build with Visual Studio? We don't care much about breakages in between 
> releases, and the other issues you listed don't affect us much either due to 
> using custom solution/project files.
>  
> Thanks for your consideration,
> Nicolas Capens
>  
> On Sun, Oct 7, 2018 at 4:51 PM Zachary Turner via llvm-dev 
> mailto:llvm-...@lists.llvm.org>> wrote:
> This has been on my mind for quite some time, but recently it's been popping 
> up more and more seeing some of the issues people have run into.
>  
> Before people get the wrong idea, let me make one thing clear.  **I am not 
> proposing we stop supporting the CMake Visual Studio generator.  I am only 
> proposing we stop supporting actually compiling with the generated project**. 
>  Yes the distinction is important, and I'll elaborate more on why later.  
> First though, here are some of the issues with the VS generator:
>  
> 1) Using MSBuild is slower than Ninja.
> 2) Unless you remember to pass -Thost=x64 on the command line, you won't be 
> able to successfully build.  We can (and have) updated the documentation to 
> indicate this, but it's not intuitive and still bites people because for some 
> reason this is not the default.
> 3) Even if you do pass -Thost=x64 to CMake, it will apparently still fail 
> sometimes.  See this thread for details: 
> http://lists.llvm.org/pipermail/cfe-dev/2018-October/059609.html 
> .
>   It seems the parallel build scheduler does not do a good job and can bring 
> a machine down.  This is not the first time though, every couple of months 
> there's a thread about how building or running tests from within VS doesn't 
> work.
> 4) Supporting it is a continuous source of errors and mistakes when writing 
> tests.  The VS generator outputs a project which can build Debug / Release 
> with a single project.  This means that 

Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

[via lldb-dev]

> -Original Message-
> From: Matthias Braun [mailto:ma...@braunis.de]
> Sent: Wednesday, October 10, 2018 3:50 PM
> To: Robinson, Paul
> Cc: jing...@apple.com; v...@apple.com; llvm-comm...@lists.llvm.org; lldb-
> d...@lists.llvm.org
> Subject: Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in
> case of missing location at block begin
> 
> 
> 
> > On Oct 10, 2018, at 12:18 PM, via llvm-commits  comm...@lists.llvm.org> wrote:
> >
> >
> >
> >> -Original Message-
> >> From: jing...@apple.com [mailto:jing...@apple.com]
> >> Sent: Wednesday, October 10, 2018 2:20 PM
> >> To: Vedant Kumar
> >> Cc: Robinson, Paul; Vedant Kumar via llvm-commits; LLDB; Matthias Braun
> >> Subject: Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location
> in
> >> case of missing location at block begin
> >>
> >>
> >>
> >>> On Oct 10, 2018, at 9:54 AM, Vedant Kumar  wrote:
> >>>
>  On Oct 10, 2018, at 9:16 AM, Matthias Braun  wrote:
> 
>  So I haven't worked much on debug info, but here's the explanation
> for
> >> my patches:
>  My original motivation was getting rid of code some code in the llvm
> >> codegen that for spills and reloads just picked the next debug location
> >> around. That just seemed wrong to me, as spills and reloads really are
> >> bookkeeping, we just move values around between registers and memory
> and
> >> none of it is related to anything the user wrote in the source program.
> So
> >> not assigning any debug information felt right for these instructions.
> >> Then people noticed line table bloat because of this and I guess we
> >> assumed that having exact line-0 annotations isn't that useful that it
> >> warrants bloating the debug information...
> >>>
> >>> Right. This doesn't seem any more arbitrary than reusing the previous
> >> instruction location, which we do all the time. I think it's a
> reasonable
> >> tradeoff.
> >
> > For spills and reloads, the next valid source location might be
> reasonable.
> > For top-of-block instructions, I really don't think so; we had this
> issue
> > in FastISel, some years back, and ultimately went with line-0 at top of
> > block because it caused way fewer problems than hoisting the next valid
> > source location.
> 
> I assume what happened in the past was that the previous debug location
> spilled over to the next basic block when the top-of-the-block instruction
> had line-0 set. I can immediately see why that is a problem. And I assume
> that was the case that was overlooked in the past. I cannot see however
> how taking the following location in the same basic block is a problem.

Because those instructions actually do something, and whether variables are
visible and expressions evaluate correctly may depend on those instructions
being executed before the debugger stops.  If you mark them with line 0 the
debugger doesn't stop. If you hoist the next source location, it does.

Spills and reloads in the middle of a block *probably* can be associated
with the next source line without doing any real damage; although it may
turn out that reloads need to attach to the previous source line.  I'd
need to see a variety of examples to be sure, one way or the other.

But long experience has taught me that instructions at the top of a block
really are better off at line 0 than at the next real source line.  If
you can prove they are *always* better off with the next source line, for
all consumers, I'd be very interested to hear about it.

But, this thread is not the best place for that; bring it up on llvm-dev
so other interested parties can see what you're looking for.
--paulr

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

Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

[via lldb-dev]

> -Original Message-
> From: Matthias Braun [mailto:ma...@braunis.de]
> Sent: Wednesday, October 10, 2018 3:48 PM
> To: Robinson, Paul
> Cc: jing...@apple.com; v...@apple.com; llvm-comm...@lists.llvm.org; lldb-
> d...@lists.llvm.org
> Subject: Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in
> case of missing location at block begin
> 
> 
> 
> > On Oct 10, 2018, at 12:18 PM, via llvm-commits  comm...@lists.llvm.org> wrote:
> >
> >
> >
> >> -Original Message-
> >> From: jing...@apple.com [mailto:jing...@apple.com]
> >> Sent: Wednesday, October 10, 2018 2:20 PM
> >> To: Vedant Kumar
> >> Cc: Robinson, Paul; Vedant Kumar via llvm-commits; LLDB; Matthias Braun
> >> Subject: Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location
> in
> >> case of missing location at block begin
> >>
> >>
> >>
> >>> On Oct 10, 2018, at 9:54 AM, Vedant Kumar  wrote:
> >>>
>  On Oct 10, 2018, at 9:16 AM, Matthias Braun  wrote:
> 
>  So I haven't worked much on debug info, but here's the explanation
> for
> >> my patches:
>  My original motivation was getting rid of code some code in the llvm
> >> codegen that for spills and reloads just picked the next debug location
> >> around. That just seemed wrong to me, as spills and reloads really are
> >> bookkeeping, we just move values around between registers and memory
> and
> >> none of it is related to anything the user wrote in the source program.
> So
> >> not assigning any debug information felt right for these instructions.
> >> Then people noticed line table bloat because of this and I guess we
> >> assumed that having exact line-0 annotations isn't that useful that it
> >> warrants bloating the debug information...
> >>>
> >>> Right. This doesn't seem any more arbitrary than reusing the previous
> >> instruction location, which we do all the time. I think it's a
> reasonable
> >> tradeoff.
> >
> > For spills and reloads, the next valid source location might be
> reasonable.
> > For top-of-block instructions, I really don't think so; we had this
> issue
> > in FastISel, some years back, and ultimately went with line-0 at top of
> > block because it caused way fewer problems than hoisting the next valid
> > source location.
> >
> > Please revert, and make top-of-block not work the same as spills and
> reloads.
> I still do not understand why the new behavior would be a problem. What
> does the debugger do with line-0 location except for setting the
> breakpoints slightly later? Spills/reloads being attribute to a following
> line or not, how would that make a difference?
> 
> I don't really care about the commit itself, it was the third step in a
> yak-shaving situation. If you prefer bigger line tables then why not
> (though then you should just enable the "UnknownLocations=Enable" behavior
> in DwarfDebug.cpp to at least be consistent.

Temper, temper.

The line tables are there for a reason. Actually multiple reasons. I have
been fussing with them for years and it is not easy to get them to work
for all consumers. Work with me here, please.
--paulr

> But before I have to go
> hunting down lldb bugs as the next step in the yak shaving I will
> revert...
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

[Matthias Braun via lldb-dev]

> On Oct 10, 2018, at 12:18 PM, via llvm-commits  
> wrote:
> 
> 
> 
>> -Original Message-
>> From: jing...@apple.com [mailto:jing...@apple.com]
>> Sent: Wednesday, October 10, 2018 2:20 PM
>> To: Vedant Kumar
>> Cc: Robinson, Paul; Vedant Kumar via llvm-commits; LLDB; Matthias Braun
>> Subject: Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in
>> case of missing location at block begin
>> 
>> 
>> 
>>> On Oct 10, 2018, at 9:54 AM, Vedant Kumar  wrote:
>>> 
 On Oct 10, 2018, at 9:16 AM, Matthias Braun  wrote:
 
 So I haven't worked much on debug info, but here's the explanation for
>> my patches:
 My original motivation was getting rid of code some code in the llvm
>> codegen that for spills and reloads just picked the next debug location
>> around. That just seemed wrong to me, as spills and reloads really are
>> bookkeeping, we just move values around between registers and memory and
>> none of it is related to anything the user wrote in the source program. So
>> not assigning any debug information felt right for these instructions.
>> Then people noticed line table bloat because of this and I guess we
>> assumed that having exact line-0 annotations isn't that useful that it
>> warrants bloating the debug information...
>>> 
>>> Right. This doesn't seem any more arbitrary than reusing the previous
>> instruction location, which we do all the time. I think it's a reasonable
>> tradeoff.
> 
> For spills and reloads, the next valid source location might be reasonable.
> For top-of-block instructions, I really don't think so; we had this issue
> in FastISel, some years back, and ultimately went with line-0 at top of 
> block because it caused way fewer problems than hoisting the next valid 
> source location.

I assume what happened in the past was that the previous debug location spilled 
over to the next basic block when the top-of-the-block instruction had line-0 
set. I can immediately see why that is a problem. And I assume that was the 
case that was overlooked in the past. I cannot see however how taking the 
following location in the same basic block is a problem.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

[Matthias Braun via lldb-dev]

> On Oct 10, 2018, at 12:18 PM, via llvm-commits  
> wrote:
> 
> 
> 
>> -Original Message-
>> From: jing...@apple.com [mailto:jing...@apple.com]
>> Sent: Wednesday, October 10, 2018 2:20 PM
>> To: Vedant Kumar
>> Cc: Robinson, Paul; Vedant Kumar via llvm-commits; LLDB; Matthias Braun
>> Subject: Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in
>> case of missing location at block begin
>> 
>> 
>> 
>>> On Oct 10, 2018, at 9:54 AM, Vedant Kumar  wrote:
>>> 
 On Oct 10, 2018, at 9:16 AM, Matthias Braun  wrote:
 
 So I haven't worked much on debug info, but here's the explanation for
>> my patches:
 My original motivation was getting rid of code some code in the llvm
>> codegen that for spills and reloads just picked the next debug location
>> around. That just seemed wrong to me, as spills and reloads really are
>> bookkeeping, we just move values around between registers and memory and
>> none of it is related to anything the user wrote in the source program. So
>> not assigning any debug information felt right for these instructions.
>> Then people noticed line table bloat because of this and I guess we
>> assumed that having exact line-0 annotations isn't that useful that it
>> warrants bloating the debug information...
>>> 
>>> Right. This doesn't seem any more arbitrary than reusing the previous
>> instruction location, which we do all the time. I think it's a reasonable
>> tradeoff.
> 
> For spills and reloads, the next valid source location might be reasonable.
> For top-of-block instructions, I really don't think so; we had this issue
> in FastISel, some years back, and ultimately went with line-0 at top of 
> block because it caused way fewer problems than hoisting the next valid 
> source location.
> 
> Please revert, and make top-of-block not work the same as spills and reloads.
I still do not understand why the new behavior would be a problem. What does 
the debugger do with line-0 location except for setting the breakpoints 
slightly later? Spills/reloads being attribute to a following line or not, how 
would that make a difference?

I don't really care about the commit itself, it was the third step in a 
yak-shaving situation. If you prefer bigger line tables then why not (though 
then you should just enable the "UnknownLocations=Enable" behavior in 
DwarfDebug.cpp to at least be consistent. But before I have to go hunting down 
lldb bugs as the next step in the yak shaving I will revert...
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

[via lldb-dev]

> -Original Message-
> From: jing...@apple.com [mailto:jing...@apple.com]
> Sent: Wednesday, October 10, 2018 2:20 PM
> To: Vedant Kumar
> Cc: Robinson, Paul; Vedant Kumar via llvm-commits; LLDB; Matthias Braun
> Subject: Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in
> case of missing location at block begin
> 
> 
> 
> > On Oct 10, 2018, at 9:54 AM, Vedant Kumar  wrote:
> >
> >> On Oct 10, 2018, at 9:16 AM, Matthias Braun  wrote:
> >>
> >> So I haven't worked much on debug info, but here's the explanation for
> my patches:
> >> My original motivation was getting rid of code some code in the llvm
> codegen that for spills and reloads just picked the next debug location
> around. That just seemed wrong to me, as spills and reloads really are
> bookkeeping, we just move values around between registers and memory and
> none of it is related to anything the user wrote in the source program. So
> not assigning any debug information felt right for these instructions.
> Then people noticed line table bloat because of this and I guess we
> assumed that having exact line-0 annotations isn't that useful that it
> warrants bloating the debug information...
> >
> > Right. This doesn't seem any more arbitrary than reusing the previous
> instruction location, which we do all the time. I think it's a reasonable
> tradeoff.

For spills and reloads, the next valid source location might be reasonable.
For top-of-block instructions, I really don't think so; we had this issue
in FastISel, some years back, and ultimately went with line-0 at top of 
block because it caused way fewer problems than hoisting the next valid 
source location.

Please revert, and make top-of-block not work the same as spills and reloads.
--paulr

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

Re: [lldb-dev] [LLDB]{Proposal} Adding new typesystem to support language like PLI/COBOL to lldb

[via lldb-dev]

John Reagan at VMS Software has made noises about adopting LLDB, in which case 
it would need to support PLI and COBOL types.  Looping him in directly.
--paulr

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Chirag 
Patel via lldb-dev
Sent: Tuesday, October 09, 2018 6:56 AM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] [LLDB]{Proposal} Adding new typesystem to support language 
like PLI/COBOL to lldb

Hello all,

I am looking into adding the new typesystem support for languages like 
PLI/COBOL.
Is anybody actively working/looking on this?

Regards,

Chirag Patel| Software Engineer
RAINCODE Mainframe to .NET
Tel : +91 080 41159811 | Mob : +91 90493 36744
www.raincodelabs.com

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

Re: [lldb-dev] [cfe-dev] [RFC] LLVM bug lifecycle BoF - triaging

[via lldb-dev]

A couple of additional data points to consider…

Approximately 30% of all reported bugs are still open.
The number of open bugs grows by roughly 28 per week. This has been consistent 
for the past 6 years, when I started tracking it.  I've reported this to the 
mailing list a few times as an FYI.
So, we do okay—70% of bugs get closed even though we have no defined 
process—but clearly we can do better.

Personally I think anything that raises bug-awareness in the community can only 
help.  All of the ideas so far have sounded great. Replacing the "new bugs" 
category with UNCONFIRMED or something like that should be good; making sure 
that everything at least gets looked at is important. Looking forward to the 
BoF.
--paulr

From: Alex Rønne Petersen [mailto:a...@alexrp.com]
Sent: Saturday, October 06, 2018 5:50 PM
To: kristof.be...@arm.com
Cc: llvm-...@lists.llvm.org; cfe-...@lists.llvm.org; lldb-dev@lists.llvm.org; 
tanyalatt...@llvm.org; n...@arm.com; Robinson, Paul
Subject: Re: [cfe-dev] [RFC] LLVM bug lifecycle BoF - triaging

Hello,

I am not a frequent poster on the LLVM mailing lists, but I happened to notice 
this thread and thought I'd weigh in.

Over 2 years ago, I reported this bug: 
https://bugs.llvm.org/show_bug.cgi?id=29102

We had to add a pretty ugly workaround in Mono to deal with that, and the 
workaround is still to this day written to apply to *all* Clang versions on 
ARM64 because we've gotten no response to the bug. This is what we're doing 
currently: https://github.com/mono/mono/blob/master/mono/utils/atomic.h#L209

I think this looks to be a pretty serious bug that shouldn't have gone 
unacknowledged for so long. If there had been any kind of response to the bug, 
I would've even been happy to cook up a patch. But, frankly, without any 
confirmation that a bug is valid, very few potential contributors are going to 
put in the time and effort to write and submit a patch and risk that it gets 
rejected because the issue it's trying to address isn't even considered a bug 
by the project maintainers.

Don't get me wrong, though - I understand from experience that "triage all the 
bugs" is much easier said than done, especially in an open source project. I 
just wanted to back up Kristof's feeling that the project is losing potential 
contributions with a concrete example of such, for what it's worth.

Regards,
Alex

On Thu, Oct 4, 2018 at 11:55 AM Kristof Beyls via cfe-dev 
mailto:cfe-...@lists.llvm.org>> wrote:
Hi all,

I’d like to share a few thoughts and analysis results on the LLVM bug life 
cycle, especially the reporting/triaging part.

As one of the few people creating llvm bugzilla accounts when people request an 
account, I started to have a feel that many reported bugs, especially by 
first-time reporters, never get any reply or feedback, let alone be acted on.
If people go through the effort of requesting an account, and then reporting 
the bug, they show motivation to contribute to the project. However, if then 
they see zero return on their effort spent, even if it’s just a confirmation of 
the bug indeed being real or an explanation of what they thought to be a bug 
isn’t actually a bug, I fear as a community we disincentify a large number of 
potential long-term contributors.

The above was all based on gut feel, so I tried to gather a bit more data to 
see if my feel was correct or not.
I scraped the bugs in bugzilla and post-processed them a bit. Below is a chart 
showing, year by year, how long it takes for a reported bug to get any comment 
from anyone besides to original reporter. If the bug is still open and didn’t 
have any reaction after half a year the chart categorizes is as an “infinite” 
response time.

 [cid:DC7C978D-FC04-470F-BAAE-CC5C623999F0]
It shows that in recent years the chance of never getting a response to a bug 
report has been increasing.
For some bugs - e.g. an experienced LLVM developer records a not-that-important 
bug in bugzilla - that may be just fine.
However, I assume that for people reporting a bug for the first time, the 
majority may look at least for confirmation that what they reported is actually 
a bug.
The chart shows (blue bars) that about 50% of first-time bug reporters never 
get any reply.

I also plotted which components get the most reported bugs that don’t get any 
reaction and remain open:
[cid:130482D2-6DEF-4796-84EC-2968F16B635C]
The percentage at the top of the bars is the percentage of bugs against that 
component that never get any reaction. The bar height shows the absolute 
numbers.


I hope that at the “Lifecycle of LLVM bug reports” BoF at the upcoming dev 
meeting in San Jose (https://llvmdev18.sched.com/event/H2T3, 17th of October, 
10.30am), we can discuss what could be done to improve the experience for 
first-time reporters and also to reduce the number of bug reports that 
seemingly get ignored completely.
By sending this email, I hope to trigger discussion before the BoF, both by 
attendees and 

Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

[Jim Ingham via lldb-dev]

> On Oct 10, 2018, at 9:54 AM, Vedant Kumar  wrote:
> 
>> On Oct 10, 2018, at 9:16 AM, Matthias Braun  wrote:
>> 
>> So I haven't worked much on debug info, but here's the explanation for my 
>> patches:
>> My original motivation was getting rid of code some code in the llvm codegen 
>> that for spills and reloads just picked the next debug location around. That 
>> just seemed wrong to me, as spills and reloads really are bookkeeping, we 
>> just move values around between registers and memory and none of it is 
>> related to anything the user wrote in the source program. So not assigning 
>> any debug information felt right for these instructions. Then people noticed 
>> line table bloat because of this and I guess we assumed that having exact 
>> line-0 annotations isn't that useful that it warrants bloating the debug 
>> information...
> 
> Right. This doesn't seem any more arbitrary than reusing the previous 
> instruction location, which we do all the time. I think it's a reasonable 
> tradeoff.
> 
> 
>> 
>> - Matthias
>> 
>>> On Oct 10, 2018, at 8:45 AM, via llvm-commits  
>>> wrote:
>>> 
>>> Sorry for being late to the party, I have been away.
>>> 
>>> I am not persuaded that this patch is functionally correct.
>>> It's lovely to reduce size, but not at the cost of telling
>>> un-truths about source locations of instructions.  If the
>>> instructions at the top of the block have no source location,
>>> and you don't like using line 0, the correct path forward is to
>>> understand why those instructions do not have a source location,
>>> not to just pick one from a nearby instruction.
> 
> I think we should do that regardless, but it's a much bigger project which 
> won't fix the bloat issues the hwasan folks ran into.
> 
> 
>>> My choice would be to revert the LLVM patch rather than make
>>> the LLDB test accommodate the un-truth.
> 
> As Jim pointed out, the LLDB test is doing a whole lot more than it needs to. 
> It should be rewritten to focus on data formatting, instead of stepping.
> 

I didn't quite say that.  I said this test inadvertently showed itself a good 
test for stepping, as well as being a test for data formatting.  So we should 
extract the part that proved its worth in catching stepping bugs into a 
stepping-only test, and then rewrite the data formatter test so it wasn't 
reliant on stepping behavior.

Jim


> vedant
> 
>>> --paulr
>>> 
 -Original Message-
 From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Jim
 Ingham via lldb-dev
 Sent: Friday, October 05, 2018 9:30 PM
 To: Vedant Kumar
 Cc: Matthias Braun; Vedant Kumar via llvm-commits; LLDB
 Subject: Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in
 case of missing location at block begin
 
 So in the test scenario, we have this code:
 
printf("// Set second break point at this line.");
(text_list.push_back(std::string("!!!")));
 
 and we have a breakpoint on the printf line.  We've just continued to hit
 the breakpoint at printf.  Then we do next twice.  That should certainly
 get us past the push_back.  If it does not that's either a bug in the line
 tables or in lldb's handling of them.  You would not expect to have to
 next three times to go from the start of the printf line to past the
 push_back of !!!.
 
 Considered as a test about stepping, we should applaud the test for having
 caught a bug, and go figure out whether the line tables are bogus in this
 instance or just innovative and lldb will have to cope...
 
 Considered as a test about data formatters, it is a little silly to try to
 drive it using next's since the push_backs are going to introduce a bunch
 of inlining and the debug information for inlining is often a bit wonky...
 
 Best course is to use the breakpoints in this test to drive from point to
 point, and make a reduced stepping test case that just shows this bad
 stepping behavior.  Then we can fix the latter test failure either in
 clang or lldb as is appropriate.
 
 Jim
 
 
> On Oct 5, 2018, at 4:18 PM, Vedant Kumar via lldb-dev >>> d...@lists.llvm.org> wrote:
> 
> No worries, I’ve relaxed the test for now in r343899 to get the bots
 going again. Essentially, the test will just step one more time to make
 sure the full effect of the push_back() is visible.
> 
> If folks on lldb-dev (cc’d) have a better idea we can try it out.
> 
> vedant
> 
>> On Oct 5, 2018, at 4:15 PM, Matthias Braun  wrote:
>> 
>> So what should we do? Revert the llvm commit, fix the LLDB test, xfail
 on lldb? I'd be fine with any but don't want to learn how lldb tests work
 at this moment...
>> 
>>> On Oct 5, 2018, at 4:11 PM, Vedant Kumar via llvm-commits >>> comm...@lists.llvm.org> wrote:
>>> 
>>> Sadly, after this commit TestDataFormatterLibcxxList.py 

Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

[Vedant Kumar via lldb-dev]

> On Oct 10, 2018, at 9:16 AM, Matthias Braun  wrote:
> 
> So I haven't worked much on debug info, but here's the explanation for my 
> patches:
> My original motivation was getting rid of code some code in the llvm codegen 
> that for spills and reloads just picked the next debug location around. That 
> just seemed wrong to me, as spills and reloads really are bookkeeping, we 
> just move values around between registers and memory and none of it is 
> related to anything the user wrote in the source program. So not assigning 
> any debug information felt right for these instructions. Then people noticed 
> line table bloat because of this and I guess we assumed that having exact 
> line-0 annotations isn't that useful that it warrants bloating the debug 
> information...

Right. This doesn't seem any more arbitrary than reusing the previous 
instruction location, which we do all the time. I think it's a reasonable 
tradeoff.


> 
> - Matthias
> 
>> On Oct 10, 2018, at 8:45 AM, via llvm-commits > > wrote:
>> 
>> Sorry for being late to the party, I have been away.
>> 
>> I am not persuaded that this patch is functionally correct.
>> It's lovely to reduce size, but not at the cost of telling
>> un-truths about source locations of instructions.  If the
>> instructions at the top of the block have no source location,
>> and you don't like using line 0, the correct path forward is to
>> understand why those instructions do not have a source location,
>> not to just pick one from a nearby instruction.

I think we should do that regardless, but it's a much bigger project which 
won't fix the bloat issues the hwasan folks ran into.


>> My choice would be to revert the LLVM patch rather than make
>> the LLDB test accommodate the un-truth.

As Jim pointed out, the LLDB test is doing a whole lot more than it needs to. 
It should be rewritten to focus on data formatting, instead of stepping.

vedant

>> --paulr
>> 
>>> -Original Message-
>>> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org 
>>> ] On Behalf Of Jim
>>> Ingham via lldb-dev
>>> Sent: Friday, October 05, 2018 9:30 PM
>>> To: Vedant Kumar
>>> Cc: Matthias Braun; Vedant Kumar via llvm-commits; LLDB
>>> Subject: Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in
>>> case of missing location at block begin
>>> 
>>> So in the test scenario, we have this code:
>>> 
>>>printf("// Set second break point at this line.");
>>>(text_list.push_back(std::string("!!!")));
>>> 
>>> and we have a breakpoint on the printf line.  We've just continued to hit
>>> the breakpoint at printf.  Then we do next twice.  That should certainly
>>> get us past the push_back.  If it does not that's either a bug in the line
>>> tables or in lldb's handling of them.  You would not expect to have to
>>> next three times to go from the start of the printf line to past the
>>> push_back of !!!.
>>> 
>>> Considered as a test about stepping, we should applaud the test for having
>>> caught a bug, and go figure out whether the line tables are bogus in this
>>> instance or just innovative and lldb will have to cope...
>>> 
>>> Considered as a test about data formatters, it is a little silly to try to
>>> drive it using next's since the push_backs are going to introduce a bunch
>>> of inlining and the debug information for inlining is often a bit wonky...
>>> 
>>> Best course is to use the breakpoints in this test to drive from point to
>>> point, and make a reduced stepping test case that just shows this bad
>>> stepping behavior.  Then we can fix the latter test failure either in
>>> clang or lldb as is appropriate.
>>> 
>>> Jim
>>> 
>>> 
 On Oct 5, 2018, at 4:18 PM, Vedant Kumar via lldb-dev >> d...@lists.llvm.org > wrote:
 
 No worries, I’ve relaxed the test for now in r343899 to get the bots
>>> going again. Essentially, the test will just step one more time to make
>>> sure the full effect of the push_back() is visible.
 
 If folks on lldb-dev (cc’d) have a better idea we can try it out.
 
 vedant
 
> On Oct 5, 2018, at 4:15 PM, Matthias Braun  > wrote:
> 
> So what should we do? Revert the llvm commit, fix the LLDB test, xfail
>>> on lldb? I'd be fine with any but don't want to learn how lldb tests work
>>> at this moment...
> 
>> On Oct 5, 2018, at 4:11 PM, Vedant Kumar via llvm-commits >> comm...@lists.llvm.org > wrote:
>> 
>> Sadly, after this commit TestDataFormatterLibcxxList.py started
>>> failing with:
>> 
>> ```
>> output: Process 67333 stopped
>> * thread #1, queue = 'com.apple.main-thread', stop reason = step over
>>frame #0: 0x00010eb0 a.out`main at main.cpp:33:16
>>   30 (text_list.push_back(std::string("smart")));
>>   31
>>   32 printf("// Set second break 

Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

[Matthias Braun via lldb-dev]

So I haven't worked much on debug info, but here's the explanation for my 
patches:
My original motivation was getting rid of code some code in the llvm codegen 
that for spills and reloads just picked the next debug location around. That 
just seemed wrong to me, as spills and reloads really are bookkeeping, we just 
move values around between registers and memory and none of it is related to 
anything the user wrote in the source program. So not assigning any debug 
information felt right for these instructions. Then people noticed line table 
bloat because of this and I guess we assumed that having exact line-0 
annotations isn't that useful that it warrants bloating the debug information...

- Matthias

> On Oct 10, 2018, at 8:45 AM, via llvm-commits  
> wrote:
> 
> Sorry for being late to the party, I have been away.
> 
> I am not persuaded that this patch is functionally correct.
> It's lovely to reduce size, but not at the cost of telling
> un-truths about source locations of instructions.  If the
> instructions at the top of the block have no source location,
> and you don't like using line 0, the correct path forward is to
> understand why those instructions do not have a source location,
> not to just pick one from a nearby instruction.
> 
> My choice would be to revert the LLVM patch rather than make
> the LLDB test accommodate the un-truth.
> --paulr
> 
>> -Original Message-
>> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org 
>> ] On Behalf Of Jim
>> Ingham via lldb-dev
>> Sent: Friday, October 05, 2018 9:30 PM
>> To: Vedant Kumar
>> Cc: Matthias Braun; Vedant Kumar via llvm-commits; LLDB
>> Subject: Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in
>> case of missing location at block begin
>> 
>> So in the test scenario, we have this code:
>> 
>>printf("// Set second break point at this line.");
>>(text_list.push_back(std::string("!!!")));
>> 
>> and we have a breakpoint on the printf line.  We've just continued to hit
>> the breakpoint at printf.  Then we do next twice.  That should certainly
>> get us past the push_back.  If it does not that's either a bug in the line
>> tables or in lldb's handling of them.  You would not expect to have to
>> next three times to go from the start of the printf line to past the
>> push_back of !!!.
>> 
>> Considered as a test about stepping, we should applaud the test for having
>> caught a bug, and go figure out whether the line tables are bogus in this
>> instance or just innovative and lldb will have to cope...
>> 
>> Considered as a test about data formatters, it is a little silly to try to
>> drive it using next's since the push_backs are going to introduce a bunch
>> of inlining and the debug information for inlining is often a bit wonky...
>> 
>> Best course is to use the breakpoints in this test to drive from point to
>> point, and make a reduced stepping test case that just shows this bad
>> stepping behavior.  Then we can fix the latter test failure either in
>> clang or lldb as is appropriate.
>> 
>> Jim
>> 
>> 
>>> On Oct 5, 2018, at 4:18 PM, Vedant Kumar via lldb-dev > d...@lists.llvm.org> wrote:
>>> 
>>> No worries, I’ve relaxed the test for now in r343899 to get the bots
>> going again. Essentially, the test will just step one more time to make
>> sure the full effect of the push_back() is visible.
>>> 
>>> If folks on lldb-dev (cc’d) have a better idea we can try it out.
>>> 
>>> vedant
>>> 
 On Oct 5, 2018, at 4:15 PM, Matthias Braun  wrote:
 
 So what should we do? Revert the llvm commit, fix the LLDB test, xfail
>> on lldb? I'd be fine with any but don't want to learn how lldb tests work
>> at this moment...
 
> On Oct 5, 2018, at 4:11 PM, Vedant Kumar via llvm-commits > comm...@lists.llvm.org> wrote:
> 
> Sadly, after this commit TestDataFormatterLibcxxList.py started
>> failing with:
> 
> ```
> output: Process 67333 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = step over
>frame #0: 0x00010eb0 a.out`main at main.cpp:33:16
>   30  (text_list.push_back(std::string("smart")));
>   31
>   32  printf("// Set second break point at this line.");
> -> 33 (text_list.push_back(std::string("!!!")));
>  ^
>   34
>   35  std::list countingList = {3141, 3142, 3142,3142,3142,
>> 3142, 3142, 3141};
>   36  countingList.sort();
> 
> 
> runCmd: frame variable text_list[0]
> output: (std::__1::basic_string,
>> std::__1::allocator >) [0] = "goofy"
> 
> Expecting sub string: goofy
> Matched
> 
> runCmd: frame variable text_list[3]
> output: None
> 
> Expecting sub string: !!!
> ```
> 
> URL: http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/10854
> 
> I confirmed that reverting this fixes the issue.
> 
> I think the 

Re: [lldb-dev] Parsing Line Table to determine function prologue?

[via lldb-dev]

If you compile with –ffunction-sections you get one sequence per function.  But 
DWARF does let you have multiple functions described by one sequence, so you 
need to accommodate that.  And, the end-prologue flag is an opcode in the 
line-number program, so if you're looking for prolog/epilog instructions you 
need to parse the whole thing anyway.
--paulr

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Zachary 
Turner via lldb-dev
Sent: Monday, October 08, 2018 3:49 PM
To: Jim Ingham
Cc: LLDB
Subject: Re: [lldb-dev] Parsing Line Table to determine function prologue?

I see.  It's not the end of the world because I can just parse the whole line 
table when requested.  It's just that in PDB-land the format is such that a) I 
know the exact address of the prologue and epilogue at the time I parse the 
function record, and b) When parsing the line table, I can quickly scan to the 
address range for the function making the whole table parsing less efficient 
than necessary.  But it's definitely sufficient.

On Mon, Oct 8, 2018 at 12:41 PM Jim Ingham 
mailto:jing...@apple.com>> wrote:
A single sequence in the line table needs to be run from beginning to end to 
make sense of it.  It doesn't really have addresses, it generally has a start 
address, then a sequence of "increment line, increment address" instructions.  
So you have to run the state machine to figure out what the addresses are.

However, the line table does not have to be one continuous sequence.  The DWARF 
docs state this explicitly, and there is an "end_sequence" instruction to 
implement this.  I can't see any reason why you couldn't get the compiler to 
emit line tables in per-function sequences, and have the debugger optimize 
reading the line table by first scanning for sequence ends to get the map of 
chunks -> addresses, and then reading the line table in those chunks.  I don't 
think anybody does this, however.  clang emitted the whole CU as one sequence 
in the few examples I had sitting around.

Jim


> On Oct 8, 2018, at 12:28 PM, Leonard Mosescu via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
>
> Even if we do need to parse the line table, could it be done just for the 
> function in question?  The debug info tells us the function's address range, 
> so is there some technical reason why it couldn't parse the line table only 
> for the given address range?
>
> My understanding is that there's one DWARF .debug_line "program" per CU, and 
> normally you'd need to "execute" the whole line number program.
>
> On Sat, Oct 6, 2018 at 8:05 PM, Zachary Turner via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> While implementing native PDB support I noticed that LLDB is asking to parse 
> an entire compile unit's line table in order to determine if 1 address is a 
> function prologue or epilogue.
>
> Is this necessary in DWARF-land?  It would be nice if I could just pass the 
> prologue and epilogue byte size directly to the constructor of the 
> lldb_private::Function object when I construct it.
>
> It seems unnecessary to parse the entire line table just to set a breakpoint 
> by function name, but this is what ends up happening.
>
> Even if we do need to parse the line table, could it be done just for the 
> function in question?  The debug info tells us the function's address range, 
> so is there some technical reason why it couldn't parse the line table only 
> for the given address range?
>
> ___
> 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] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

[via lldb-dev]

Sorry for being late to the party, I have been away.

I am not persuaded that this patch is functionally correct.
It's lovely to reduce size, but not at the cost of telling
un-truths about source locations of instructions.  If the
instructions at the top of the block have no source location,
and you don't like using line 0, the correct path forward is to
understand why those instructions do not have a source location,
not to just pick one from a nearby instruction.

My choice would be to revert the LLVM patch rather than make
the LLDB test accommodate the un-truth.
--paulr

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Jim
> Ingham via lldb-dev
> Sent: Friday, October 05, 2018 9:30 PM
> To: Vedant Kumar
> Cc: Matthias Braun; Vedant Kumar via llvm-commits; LLDB
> Subject: Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in
> case of missing location at block begin
> 
> So in the test scenario, we have this code:
> 
> printf("// Set second break point at this line.");
> (text_list.push_back(std::string("!!!")));
> 
> and we have a breakpoint on the printf line.  We've just continued to hit
> the breakpoint at printf.  Then we do next twice.  That should certainly
> get us past the push_back.  If it does not that's either a bug in the line
> tables or in lldb's handling of them.  You would not expect to have to
> next three times to go from the start of the printf line to past the
> push_back of !!!.
> 
> Considered as a test about stepping, we should applaud the test for having
> caught a bug, and go figure out whether the line tables are bogus in this
> instance or just innovative and lldb will have to cope...
> 
> Considered as a test about data formatters, it is a little silly to try to
> drive it using next's since the push_backs are going to introduce a bunch
> of inlining and the debug information for inlining is often a bit wonky...
> 
> Best course is to use the breakpoints in this test to drive from point to
> point, and make a reduced stepping test case that just shows this bad
> stepping behavior.  Then we can fix the latter test failure either in
> clang or lldb as is appropriate.
> 
> Jim
> 
> 
> > On Oct 5, 2018, at 4:18 PM, Vedant Kumar via lldb-dev  d...@lists.llvm.org> wrote:
> >
> > No worries, I’ve relaxed the test for now in r343899 to get the bots
> going again. Essentially, the test will just step one more time to make
> sure the full effect of the push_back() is visible.
> >
> > If folks on lldb-dev (cc’d) have a better idea we can try it out.
> >
> > vedant
> >
> >> On Oct 5, 2018, at 4:15 PM, Matthias Braun  wrote:
> >>
> >> So what should we do? Revert the llvm commit, fix the LLDB test, xfail
> on lldb? I'd be fine with any but don't want to learn how lldb tests work
> at this moment...
> >>
> >>> On Oct 5, 2018, at 4:11 PM, Vedant Kumar via llvm-commits  comm...@lists.llvm.org> wrote:
> >>>
> >>> Sadly, after this commit TestDataFormatterLibcxxList.py started
> failing with:
> >>>
> >>> ```
> >>> output: Process 67333 stopped
> >>> * thread #1, queue = 'com.apple.main-thread', stop reason = step over
> >>> frame #0: 0x00010eb0 a.out`main at main.cpp:33:16
> >>>30 (text_list.push_back(std::string("smart")));
> >>>31
> >>>32 printf("// Set second break point at this line.");
> >>> -> 33 (text_list.push_back(std::string("!!!")));
> >>>  ^
> >>>34
> >>>35 std::list countingList = {3141, 3142, 3142,3142,3142,
> 3142, 3142, 3141};
> >>>36 countingList.sort();
> >>>
> >>>
> >>> runCmd: frame variable text_list[0]
> >>> output: (std::__1::basic_string,
> std::__1::allocator >) [0] = "goofy"
> >>>
> >>> Expecting sub string: goofy
> >>> Matched
> >>>
> >>> runCmd: frame variable text_list[3]
> >>> output: None
> >>>
> >>> Expecting sub string: !!!
> >>> ```
> >>>
> >>> URL: http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/10854
> >>>
> >>> I confirmed that reverting this fixes the issue.
> >>>
> >>> I think the problem is that we’re breaking on an instruction that
> looks like it’s on line 33, but it’s actually “before” the full effect of
> the push_back() is visible.
> >>>
> >>> In which case the test is wrong, because it’s setting the breakpoint
> too early…
> >>>
> >>> vedant
> >>>
>  On Oct 5, 2018, at 11:29 AM, Matthias Braun via llvm-commits  comm...@lists.llvm.org> wrote:
> 
>  Author: matze
>  Date: Fri Oct  5 11:29:24 2018
>  New Revision: 343874
> 
>  URL: http://llvm.org/viewvc/llvm-project?rev=343874=rev
>  Log:
>  DwarfDebug: Pick next location in case of missing location at block
> begin
> 
>  Context: Compiler generated instructions do not have a debug location
>  assigned to them. However emitting 0-line records for all of them
> bloats
>  the line tables for very little benefit so we usually avoid doing
> that.
> 
>  Not emitting 

Re: [lldb-dev] [llvm-dev] Should we stop supporting building with Visual Studio?

[Zachary Turner via lldb-dev]

So IIUC this all 1 big solution, one component of which is LLVM? How do you
get them all together in 1 big solution?
On Wed, Oct 10, 2018 at 7:16 AM Nicolas Capens 
wrote:

> Hi Zachary,
>
> We use LLVM JIT in SwiftShader, which is used by Google Chrome and Android
> (Emulator). Most development takes place in Visual Studio, where it builds
> as part of the rest of the SwiftShader solution. So we care about LLVM
> source files compiling successfully within Visual Studio.
>
> Would it be reasonable to at least ensure that major releases (7.0, 8.0,
> etc.) build with Visual Studio? We don't care much about breakages in
> between releases, and the other issues you listed don't affect us much
> either due to using custom solution/project files.
>
> Thanks for your consideration,
> Nicolas Capens
>
> On Sun, Oct 7, 2018 at 4:51 PM Zachary Turner via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> This has been on my mind for quite some time, but recently it's been
>> popping up more and more seeing some of the issues people have run into.
>>
>> Before people get the wrong idea, let me make one thing clear.  **I am
>> not proposing we stop supporting the CMake Visual Studio generator.  I am
>> only proposing we stop supporting actually compiling with the generated
>> project**.  Yes the distinction is important, and I'll elaborate more on
>> why later.  First though, here are some of the issues with the VS generator:
>>
>> 1) Using MSBuild is slower than Ninja.
>> 2) Unless you remember to pass -Thost=x64 on the command line, you won't
>> be able to successfully build.  We can (and have) updated the documentation
>> to indicate this, but it's not intuitive and still bites people because for
>> some reason this is not the default.
>> 3) Even if you do pass -Thost=x64 to CMake, it will apparently still fail
>> sometimes.  See this thread for details:
>> http://lists.llvm.org/pipermail/cfe-dev/2018-October/059609.html.  It
>> seems the parallel build scheduler does not do a good job and can bring a
>> machine down.  This is not the first time though, every couple of months
>> there's a thread about how building or running tests from within VS doesn't
>> work.
>> 4) Supporting it is a continuous source of errors and mistakes when
>> writing tests.  The VS generator outputs a project which can build Debug /
>> Release with a single project.  This means that `CMAKE_BUILD_TYPE=Debug` is
>> a no-op on this generator.  The reason this matters for the test suite is
>> because `${CMAKE_CURRENT_BINARY_DIR}` isn't sufficient to identify the
>> location of the binaries.  You need 
>> `${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}`
>> instead.
>>
>> There is a continuous source of problems in our CMake [1, 2, 3, 4, 5].
>> It also affects tests, and every time someone adds a new lit site
>> configuration, they have to remember to add this magic block of code:
>>
>> # Support substitution of the tools_dir with user parameters. This is
>> # used when we can't determine the tool dir at configuration time.
>> try:
>> config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
>> config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
>> except KeyError:
>> e = sys.exc_info()[1]
>> key, = e.args
>> lit_config.fatal("unable to find %r parameter, use
>> '--param=%s=VALUE'" % (key,key))
>>
>> to the file (even though only about 2 people actually understand what
>> this does), which has caused problems several times.
>>
>> 5) VSCode and Visual Studio both support opening CMake projects directly
>> now, which bypasses MSBuild.  I don't know how well Visual Studio supports
>> LLVM's CMake, but the last time I tried it with VSCode on Linux it worked
>> fine.
>>
>> 
>>
>> I mentioned earlier that the distinction between not *building* with a
>> VS-generated project and not supporting the VS generator is important.
>>
>> I don't want to speak for everyone, but I believe that *most* people use
>> the VS generator because they want IDE support for their projects.  They
>> want to be able to browse code, hit F5 to debug, F9 to set breakpoints,
>> etc.  They don't necessarily care that Ctrl+Shift+B is how the code is
>> generated versus some other incantation.  I'm asserting that it's possible
>> to still have all the things people actually want from the VS generator
>> without actually building from inside of VS.  In fact, I've been doing this
>> for several years.  The workflow is:
>>
>> 1) Run CMake twice, generating to separate output directories.  Once
>> using -G "Visual Studio 15 2017" and once using -G Ninja, each to different
>> directories.
>>
>> 2) Open the VS one.  You have full IDE support.
>>
>> 3) Instead of hitting Ctrl+Shift+B to build, have a command prompt window
>> open and type ninja.  Wait for it to complete.  If you want to you can make
>> a custom tool command in Visual Studio so that you can access this from a
>> keyboard shortcut.
>>
>> 4) When you want to debug, set your 

Re: [lldb-dev] [llvm-dev] Should we stop supporting building with Visual Studio?

[Nicolas Capens via lldb-dev]

Hi Zachary,

We use LLVM JIT in SwiftShader, which is used by Google Chrome and Android
(Emulator). Most development takes place in Visual Studio, where it builds
as part of the rest of the SwiftShader solution. So we care about LLVM
source files compiling successfully within Visual Studio.

Would it be reasonable to at least ensure that major releases (7.0, 8.0,
etc.) build with Visual Studio? We don't care much about breakages in
between releases, and the other issues you listed don't affect us much
either due to using custom solution/project files.

Thanks for your consideration,
Nicolas Capens

On Sun, Oct 7, 2018 at 4:51 PM Zachary Turner via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> This has been on my mind for quite some time, but recently it's been
> popping up more and more seeing some of the issues people have run into.
>
> Before people get the wrong idea, let me make one thing clear.  **I am not
> proposing we stop supporting the CMake Visual Studio generator.  I am only
> proposing we stop supporting actually compiling with the generated
> project**.  Yes the distinction is important, and I'll elaborate more on
> why later.  First though, here are some of the issues with the VS generator:
>
> 1) Using MSBuild is slower than Ninja.
> 2) Unless you remember to pass -Thost=x64 on the command line, you won't
> be able to successfully build.  We can (and have) updated the documentation
> to indicate this, but it's not intuitive and still bites people because for
> some reason this is not the default.
> 3) Even if you do pass -Thost=x64 to CMake, it will apparently still fail
> sometimes.  See this thread for details:
> http://lists.llvm.org/pipermail/cfe-dev/2018-October/059609.html.  It
> seems the parallel build scheduler does not do a good job and can bring a
> machine down.  This is not the first time though, every couple of months
> there's a thread about how building or running tests from within VS doesn't
> work.
> 4) Supporting it is a continuous source of errors and mistakes when
> writing tests.  The VS generator outputs a project which can build Debug /
> Release with a single project.  This means that `CMAKE_BUILD_TYPE=Debug` is
> a no-op on this generator.  The reason this matters for the test suite is
> because `${CMAKE_CURRENT_BINARY_DIR}` isn't sufficient to identify the
> location of the binaries.  You need 
> `${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}`
> instead.
>
> There is a continuous source of problems in our CMake [1, 2, 3, 4, 5].  It
> also affects tests, and every time someone adds a new lit site
> configuration, they have to remember to add this magic block of code:
>
> # Support substitution of the tools_dir with user parameters. This is
> # used when we can't determine the tool dir at configuration time.
> try:
> config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
> config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
> except KeyError:
> e = sys.exc_info()[1]
> key, = e.args
> lit_config.fatal("unable to find %r parameter, use '--param=%s=VALUE'"
> % (key,key))
>
> to the file (even though only about 2 people actually understand what this
> does), which has caused problems several times.
>
> 5) VSCode and Visual Studio both support opening CMake projects directly
> now, which bypasses MSBuild.  I don't know how well Visual Studio supports
> LLVM's CMake, but the last time I tried it with VSCode on Linux it worked
> fine.
>
> 
>
> I mentioned earlier that the distinction between not *building* with a
> VS-generated project and not supporting the VS generator is important.
>
> I don't want to speak for everyone, but I believe that *most* people use
> the VS generator because they want IDE support for their projects.  They
> want to be able to browse code, hit F5 to debug, F9 to set breakpoints,
> etc.  They don't necessarily care that Ctrl+Shift+B is how the code is
> generated versus some other incantation.  I'm asserting that it's possible
> to still have all the things people actually want from the VS generator
> without actually building from inside of VS.  In fact, I've been doing this
> for several years.  The workflow is:
>
> 1) Run CMake twice, generating to separate output directories.  Once using
> -G "Visual Studio 15 2017" and once using -G Ninja, each to different
> directories.
>
> 2) Open the VS one.  You have full IDE support.
>
> 3) Instead of hitting Ctrl+Shift+B to build, have a command prompt window
> open and type ninja.  Wait for it to complete.  If you want to you can make
> a custom tool command in Visual Studio so that you can access this from a
> keyboard shortcut.
>
> 4) When you want to debug, set your startup project (as you normally
> would), right click and hit properties, go to Debugging, change Command
> from $(TargetPath) to  want to debug>.
>
> 5) Hit F5.
>
> In short, with only 2 simple additional steps (run CMake an extra time,
> and type a path into a window), people can