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_g
I committed a fix in r312008. Please test it to verify that it resolves your
issue.
Thanks,
-Chris
> On Aug 28, 2017, at 8:41 PM, Ramana wrote:
>
> Thank you, Chris. Looking forward to the patch.
>
> On Tue, Aug 29, 2017 at 1:28 AM, Chris Bieneman wrote:
>> I had a chance to look into this m
I had a chance to look into this more, and I found a bug in the listen
behavior. I'm testing a solution to it now. Will post it if it resolves the
issue.
-Chris
> On Aug 25, 2017, at 10:36 AM, Greg Clayton via lldb-dev
> wrote:
>
> Maybe we can make it open only an IPv4 socket for lldb-serve
Since lldb-server only supports running on a limited set of host operating
systems it is hard for me to diagnose the issue completely, but I suspect the
problem is caused by the fact that the new listening code can open more than
one socket, and TCPSocket::GetLocalPortNumber() may be misbehaving
I think in the common case of listening for a remote connection infinite (or
very very long) timeout with signal interrupt is the preferred approach. There
are other situations where we use SelectHelper with smaller timeouts, and I
think ultimately we should replace SelectHelper with MainLoop be
Ultimately I think the solution here is two changes
(1) We should add a timeout to MainLoop so that it doesn't wait forever unless
we really want to wait forever.
(2) MainLoop can exit on sigint for any platform that has ppoll, pselect, or
kevent, so we should probably set that up too.
-Chris
(+LLDB-Dev) most of the LLDB developers hang out there more than on LLVM-Dev.
> On Apr 26, 2017, at 12:26 PM, Demi Marie Obenour via llvm-dev
> wrote:
>
> LLDB currently uses a client-server architecture. That appears fine,
> but runs into an annoying security problem: other users on the same
I pushed a fix that should resolve this in r290934.
Sorry for the breakage!
-Chris
> On Dec 25, 2016, at 10:18 AM, Sylvestre Ledru via lldb-dev
> wrote:
>
> Hello
>
> Recently (couple of weeks), the generation of the apt.llvm.org packages
> is failing because some lldb binaries are sometime n
So, I want to delete the testcases symlink from the LLDB tree, and move the
tests out of the packages directory into tests/testcases.
A few reasons why I want to do this:
(1) I can't imagine symlinks in SVN is something that works well on platforms
that don't support symlinks (like Windows)
(2)
> On Dec 6, 2016, at 9:32 AM, Pavel Labath wrote:
>
> Ah, I totally forgot about the llvm DEBUG macro. I would be open to
> trying merge these two approaches together. However, I think our's is
> a much more heavy-weight system, so it might be too heavy for llvm,
> and I am not sure how much wou
My only concern reading this is that LLVM already has a similar mechanism for
channel-based logging that is used throughout the backends. Is there a reason
to invent our own? Maybe we can take what is in LLVM, enhance it and use shared
functionality?
There are a few differences between your sol
Mehdi,
I think your second approach is the better option. Going with the first option
means we would need to remove references to llvm-config.h in ADT, which I don't
think is a simple task.
-Chris
> On Nov 18, 2016, at 4:23 PM, Mehdi Amini via llvm-dev
> wrote:
>
>
>> On Nov 18, 2016, at 3
> On Oct 20, 2016, at 1:00 PM, Tamas Berghammer via lldb-dev
> wrote:
>
> Building LLDB with cmake is already supported on all operating systems
> (including Darwin) for a while so that shouldn't be a blocker.
While this is technically true, the LLDB test suite makes a lot of assumptions
tha
vm.org:8011/builders/lldb-amd64-ninja-netbsd7/builds/6775
>
>> On 30.09.2016 01:04, Chris Bieneman via lldb-dev wrote:
>> Hal, thanks for the heads up. I just committed a patch that should resolve
>> this in r282803.
>>
>> Thanks!
>> -Chris
>>
>&
Hal, thanks for the heads up. I just committed a patch that should resolve this
in r282803.
Thanks!
-Chris
> On Sep 29, 2016, at 1:49 PM, Hal Finkel wrote:
>
> - Original Message -
>> From: "Hal Finkel via lldb-dev"
>> To: lldb-dev@lists.llvm.org
>> Sent: Thursday, September 29, 2016
> On Sep 10, 2016, at 12:11 PM, René J.V. Bertin via lldb-dev
> wrote:
>
> On Saturday September 10 2016 17:26:26 Michał Górny wrote:
>
> Re: MIUtilParse: I'm building the 3.9.0 release so no worries that the class
> has been added back supposing it was removed *after* the release.
>
>>> Agr
> On Aug 2, 2016, at 4:46 PM, Hans Wennborg wrote:
>
> Dear everyone,
>
> It's time for the release notes nagging email.
>
> We have release notes for LLVM, Clang, clang-tools-extra, lld, and
> Polly. (If there are more, please let me know.)
>
> Most of these are pretty empty files; see e.g.
My personal 2 cents is that I’d love to see us move to github and a git-native
workflow. I’m already on a mostly git workflow and the only thing that tears me
out of it is git-svn, which corrupts itself way too often.
As a late-comer on the thread I do have a few thoughts I want to share based o
flood gates on those kinds of cascading changes in
case these patches need to be reverted for some reason.
Thanks,
-Chris
> On May 31, 2016, at 11:22 AM, Chris Bieneman via lldb-dev
> wrote:
>
> Just an FYI. Later today I’ll be updating the CMake minimum version to 3.4.3.
> In
Just an FYI. Later today I’ll be updating the CMake minimum version to 3.4.3.
In advance of the transition I’ve posted a bunch of patches:
LLVM: http://reviews.llvm.org/D20822
Clang: http://reviews.llvm.org/D20823
Compiler-RT: http://reviews.llvm.org/D20824
LLDB: http://reviews.llvm.org/D20826
li
Meant to send this yesterday, but I want to remind everyone that we’re going to
be raising the CMake minimum version to 3.4.3 next week.
If you maintain bots please ensure that your bots are updated by end of day
5/29 so that we can move on 5/30 (next Monday).
I have already heard from most bot
21 matches
Mail list logo