Thanks for the info. I will keep that in mind.
On Mon, Aug 28, 2017 at 11:05 PM, Jim Ingham wrote:
> That will be great! Last time we were more aggressive about normalizing
> paths we caused a decent performance regression by normalizing all the
> paths every time we did a file-name compare for
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 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,
Very nice! Look forward to seeing what you find.
> On Aug 28, 2017, at 12:58 PM, Chris Bieneman wrote:
>
> 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,
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
Hello everyone,
Source, binaries and docs for LLVM-5.0.0-rc3 are now available at
http://prereleases.llvm.org/5.0.0/#rc3
(I'll add more binaries as they become available.)
We're a little behind schedule, but hopefully will be ready for the
final release soon.
Please report any problems you find
I see there's a patch in progress to fix this: https://reviews.llvm.org/D36049
Since the issue was raised so late in the process, I don't think it
will get fixed for 5.0.0 however. Maybe for 5.0.1.
Thanks,
Hans
On Mon, Aug 28, 2017 at 12:40 AM, Dr.-Ing. Christoph Cullmann
wrote:
> Hi,
>
> one i
On 26 Aug 2017, at 00:52, Hans Wennborg via Release-testers
wrote:
>
> 5.0.0-rc3 was just tagged.
>
> This is a release candidate in the real sense: if nothing bad comes up
> in testing, this is what the release is going to look like.
Built and tested, no changes with respect to the previous r
I built lldb with XCode 8.3.3 on OX 10.12.6, using the latest from
https://github.com/llvm-mirror/lldb.git, but I'm when I run the tests, I get
nothing but errors. The errors are mostly related to being unable to find
standard C++ headers like iostream, exception, cstdlib, chrono, etc.
I'm usi
Since the address is mostly only interesting "when it goes bad" which should be
infrequent, we want to have the value be the easiest thing to pick out. It's a
little harder to tell in isolation, what you're really going to see is
something like:
A:
(int) y = 33
(int) z = 33
(int &) x =
That will be great! Last time we were more aggressive about normalizing paths
we caused a decent performance regression by normalizing all the paths every
time we did a file-name compare for setting breakpoints. If you look at
FileSpec::Equal we added some "is it worth doing this work" prepara
On Fri, Aug 25, 2017 at 3:52 PM, Hans Wennborg wrote:
> Dear testers,
>
> 5.0.0-rc3 was just tagged.
>
> This is a release candidate in the real sense: if nothing bad comes up
> in testing, this is what the release is going to look like.
>
> Please build, test and upload binaries to the sftp (use
If we are pulling in the expression parser, that would explain our issues. If
this currently happens in lldb-server we need to add LLVMRuntimeDyld to the
link libraries. I know some people at Google have looked into getting
lldb-server to link against as little as possible, and maybe this is jus
> On Aug 25, 2017, at 4:15 PM, Jim Ingham wrote:
>
> If that’s the expectation, you have to obey it... Xcode is pretty careful
> to only act on the elements that were visible in a view, which made the
> locals view much less heavy-weight. But that took some work on their end.
>
> More to t
Hi Greg,
IRExecutionUnit.cpp looks like the origin of at least some of the undefined
symbols:
.../llvm/include/llvm/ExecutionEngine/RTDyldMemoryManager.h:61: undefined
reference to `vtable for llvm::RTDyldMemoryManager'
.../llvm/include/llvm/ExecutionEngine/JITSymbol.h:223: undefined reference
Looks like a dependency issue in LLVM? Who was using this function? Why do we
need LLVMRuntimeDyld in lldb-server? We shouldn't have to use it. I know we
currently have some issues in lldb-server where it is pulling in too much
stuff, so we definitely don't want to include this just to fix a lin
I've built lldb in tree on Linux (RHEL 7.3) with a shared library configuration:
CC=/usr/bin/clang CXX=/usr/bin/clang++ \
cmake -G Ninja ../llvm \
-DBUILD_SHARED_LIBS=true \
...
The lldb-server binary does not link for me, as I get unresolved symbols
including:
llvm::RuntimeDyld::MemoryManag
> On Aug 27, 2017, at 11:59 AM, Johan Engelen via lldb-dev
> wrote:
>
> Hi all,
> Consider this code:
> ```
> void foo(int& x)
> {
> ++x;
> // Breakpoint
> }
> ```
>
> Reference parameter `x` is shown like this:
> ```
> (lldb) frame variable
> (int &) x = 0x7fff5fbff5e8 (&x = 33)
Hi,
Uploaded ARM & AArch64:
ee9e89f1d5f8a5fb84cef6c82ded694c5c427e16
clang+llvm-5.0.0-rc3-aarch64-linux-gnu.tar.xz
a8b38e91288b07b2899c397373c018c6c5f6f207
clang+llvm-5.0.0-rc3-armv7a-linux-gnueabihf.tar.xz
The libunwind tests are still failing. I have reopened the bug:
https://bugs.llvm.org/show
Thanks Jim for the help. I would definitely like to work on this PR soon.
Filed the PR here
https://bugs.llvm.org/show_bug.cgi?id=34341
Regards,
Karan
On Thu, Aug 24, 2017 at 11:17 PM, Jim Ingham wrote:
>
> > On Aug 24, 2017, at 10:06 AM, karnajit wangkhem
> wrote:
> >
> > Hi Jim,
> >
> > Tha
https://bugs.llvm.org/show_bug.cgi?id=34341
Bug ID: 34341
Summary: Fix lldb to use path normalization for these listed
scenarios
Product: lldb
Version: unspecified
Hardware: PC
OS: FreeBSD
Status
Hello
I am not sure to understand how this relates to the 5.0.0 work?
For now, it is broken because of a gcc bug:
https://bugs.llvm.org/show_bug.cgi?id=34150
I am planning to upgrade the gcc version to 4.9 to workaround this
issue. Probably this week.
Sylvestre
Le 28/08/2017 à 09:40, Andrew
21 matches
Mail list logo
