On Mon, Aug 24, 2015 at 05:37:43PM -0700, via lldb-dev wrote:
> On Mon, Aug 24, 2015 at 03:37:52PM -0700, Todd Fiala via lldb-dev wrote:
> > On Linux on non-virtualized hardware, I currently see the failures below on
> > Ubuntu 14.04.2 using a setup like this:
> > [...]
> >
> > ninja check-lldb ou
On Mon, Aug 24, 2015 at 03:37:52PM -0700, Todd Fiala via lldb-dev wrote:
> On Linux on non-virtualized hardware, I currently see the failures below on
> Ubuntu 14.04.2 using a setup like this:
> [...]
>
> ninja check-lldb output:
>
> Ran 394 test suites (15 failed) (3.807107%)
> Ran 474 test case
Hello everyone,
Source, binaries and docs for LLVM 3.7.0-rc3 are now available at
http://llvm.org/pre-releases/3.7.0/
We are getting very, very close to the final release, so if you were
planning to do any testing before this ships, now is probably the last
chance.
Patches to the release notes a
It seems this is a cmake vs autoconf thing. With cmake, it builds
correctly, but with autoconf I get the same error as you.
I probably shouldn't have made this change while we were in the
release process as it was potentially risky :-/ I've reverted it now,
so hopefully the next build should be pr
Ah drats! Okay. Baby steps :-D
On Mon, Aug 24, 2015 at 4:29 PM, Chaoren Lin wrote:
> Ah okay, so we are working with libc++ on Ubuntu, that's good to hear.
>> Pre-14.04 I gave up on it.
>
>
> We're still using libstdc++ for lldb itself. libc++ is used to compile
> inferiors for the TestDataFo
>
> Ah okay, so we are working with libc++ on Ubuntu, that's good to hear.
> Pre-14.04 I gave up on it.
We're still using libstdc++ for lldb itself. libc++ is used to compile
inferiors for the TestDataFormatterLibcc* tests. I don't actually know if
libc++ works with lldb. Sorry to get your hopes
On Mon, Aug 24, 2015 at 4:03 PM, Greg Clayton wrote:
> We should have a decorator like:
>
> @skipLinuxUnlessInstalled("/usr/lib/libc++.so")
>
> or something that tells us to install this library and fails the test
> suite before you run anything.
>
>
Yeah, I like that idea, Greg. We shouldn't re
On Mon, Aug 24, 2015 at 4:01 PM, Chaoren Lin wrote:
> The TestDataFormatterLibcc* tests require libc++-dev:
>
> $ sudo apt-get install libc++-dev
>
>
Ah okay, so we are working with libc++ on Ubuntu, that's good to hear.
Pre-14.04 I gave up on it.
Will cmake automatically choose libc++ if it is
We should have a decorator like:
@skipLinuxUnlessInstalled("/usr/lib/libc++.so")
or something that tells us to install this library and fails the test suite
before you run anything.
> On Aug 24, 2015, at 4:01 PM, Chaoren Lin via lldb-dev
> wrote:
>
> The TestDataFormatterLibcc* tests require
That doesn't seem to be right, you had a typename before:
(lldb) pp Ty
Fn(Void -> Int)*
=
Make sure everything is setup and is where you were stopped before and that you
use the same "Ty" variable you did before. I have seen function types have
newlines in them in the past.
> On Aug 24, 2015,
The TestDataFormatterLibcc* tests require libc++-dev:
$ sudo apt-get install libc++-dev
On Mon, Aug 24, 2015 at 3:42 PM, Todd Fiala via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
>
> On Mon, Aug 24, 2015 at 3:39 PM, Zachary Turner
> wrote:
>
>> Can't comment on the failures for Linux, but I don
Hm, that doesn't seem to be it.
(lldb) pp R
var ~UnType
typename = ""
() =
On Mon, Aug 24, 2015 at 12:51 PM, Greg Clayton wrote:
> The type name for "Ty" might have a newline in it. Try this:
>
>
>res = frame.EvaluateExpression("%s->dump()" % command)
>print >>result, 'typename = "%s"'
On Mon, Aug 24, 2015 at 3:39 PM, Zachary Turner wrote:
> Can't comment on the failures for Linux, but I don't think we have a good
> handle on the unexpected successes. I only added that information to the
> output about a week ago, before that unexpected successes were actually
> going unnotice
Can't comment on the failures for Linux, but I don't think we have a good
handle on the unexpected successes. I only added that information to the
output about a week ago, before that unexpected successes were actually
going unnoticed.
It's likely that someone could just go in there and remove th
Hi all,
I'm just trying to get a handle on current lldb test failures across
different platforms.
On Linux on non-virtualized hardware, I currently see the failures below on
Ubuntu 14.04.2 using a setup like this:
* stock linker (ld.bfd),
* g++ 4.9.2
* cmake
* ninja
* libstdc++
ninja check-lldb
https://llvm.org/bugs/show_bug.cgi?id=24558
Bug ID: 24558
Summary: Inferior not getting reaped in certain situations
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: nor
https://llvm.org/bugs/show_bug.cgi?id=24557
Bug ID: 24557
Summary: A few edge cases related to quote handling are broken
on Windows
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
The type name for "Ty" might have a newline in it. Try this:
res = frame.EvaluateExpression("%s->dump()" % command)
print >>result, 'typename = "%s"' % (res.GetType().GetName())
print >>result, res
See if the double quote is on the next line.
> On Aug 22, 2015, at 11:58 AM, Ramkumar Ra
I guess we can just make pid == 1 and tid == 1 in this case. As long as a stop
reply is responding we should be able to debug.
> On Aug 23, 2015, at 11:51 PM, Jaydeep Patil wrote:
>
> Hi Greg,
>
> The '?' packet always returns 'S05'. There is no thread information available
> in any of the pa
https://llvm.org/bugs/show_bug.cgi?id=24553
Bug ID: 24553
Summary: pro hand does not handle all SIGSEGV/SIGBUS signals
Product: lldb
Version: 3.2
Hardware: PC
OS: MacOS X
Status: NEW
Severity: normal
https://llvm.org/bugs/show_bug.cgi?id=24551
Bug ID: 24551
Summary: instruction step over thread exit fails on linux
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
https://llvm.org/bugs/show_bug.cgi?id=23980
lab...@google.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://llvm.org/bugs/show_bug.cgi?id=24548
lab...@google.com changed:
What|Removed |Added
CC||lab...@google.com
Assignee|lldb-de
23 matches
Mail list logo
