There's a subtle bug that is pervasive throughout the test suite. Consider
the following seemingly innocent test class.
class MyTest(TestBase);
def setUp():
TestBase.setUp()#1
# Do some stuff #2
self.addTearDownHook(lambda: self.foo()) #3
def test_inte
Hi Ying,
Our dotest.py lldb test results go through that lit test parser system? I
see XPASS happen frequently (and in fact is my whole reason for starting a
thread on getting rid of flakey tests, or making them run enough times so
that their output can be a useful signal rather than useless). A
>>
>> The other bad thing is even after you normalize the paths you are comparing:
>>
>> /mathworks/devel/sbs/34/rramacha.idivide-final-lap/3p_mirror/maci64/LLVM/include/llvm/ADT/ilist.h
>> /mathworks/devel/sandbox/rramacha/3p-tmw-osx/3p/derived/maci64/LLVM/llvm/include/llvm/ADT/ilist.h
>>
>> A
>>
>> Are you pulling in data from two different copies of LLVM in your project?
>> Or is something in here symlink to the other somewhere?
>
> Excellent find. Yes, 3p_mirror is a symlink to the 3p-tmw-osx location.
>
>> So to sum up: LLDB uniques types by decl file + decl line + byte size +
>
[Quoting entire email for the benefit of everyone else]
On Tue, Oct 20, 2015 at 7:39 PM, Greg Clayton wrote:
> Ok, so try this on all of your dSYM files:
>
> 1 - load the dsym file into lldb:
>
> % xcrun lldb
> libmwcgir_vm_rt.dylib.dSYM/Contents/Resources/DWARF/libmwcgir_vm_rt.dylib
> (lldb) im
Hi Zachary,
The big unknown here is how to make the buildbots understand unit test
> failures and trigger a failure when ninja check-lldb-unit fails.
>
There're two conditions buildbot will identity a test step as failure.
One is that the command has non-zero return code.
The other is that there'
> On Oct 19, 2015, at 4:40 PM, Zachary Turner via lldb-dev
> wrote:
>
> Yea, I definitely agree with you there.
>
> Is this going to end up with an @expectedFlakeyWindows, @expectedFlakeyLinux,
> @expectedFlakeyDarwin, @expectedFlakeyAndroid, @expectedFlakeyFreeBSD?
>
> It's starting to ge
Well that's basically what I meant with this:
@test_status(status=flaky, host=[win, linux, android, darwin, bsd],
target=[win, linux, android, darwin, bsd], compiler=[gcc, clang],
debug_info=[dsym, dwarf, dwo])
but it has keyword parameters that allow you to specify the conditions
under which the
I'm not totally sure yet here.
Right now there is a generic category mechanism, but it is only settable
via a file in a directory, or overridden via the test case class method
called getCategories().
I think I'd want a more general decorator that allows you to tag a method
itself with categories.
Hi,
This does not happen with lldb-330.0.48, which ships with OS X, but
happens with HEAD:
frame #0: 0x000101c3ce8c libmwcgir_vm_rt.dylib`(anonymous
namespace)::CgJITMemManager::endFunctionBody(this=0x00010a715610,
F=0x00010a6da200, FunctionStart="�?^\n\x01",
FunctionEnd="
> On Oct 20, 2015, at 9:57 AM, Ramkumar Ramachandra wrote:
>
> Greg Clayton wrote:
>> Yes I have seen a bunch of problems like this on linux due to types being
>> incomplete in the debug info (my guess). But I would like to verify that the
>> manual DWARF indexing isn't to blame for this. We h
My guess is that there is a different temporary symbol for differing
architectures and possibly depending on which file format (mach-o or ELF) you
are targeting. MIPS probably happens to use '$'. I know mach-o files use "L" as
the temporary symbol prefix, ELF tends to use '.'. Not sure where thi
What is this not happening on any other architecture? Is the "$" special for
MIPS and not for other architectures? We really don't want to remove the '$' as
we want the symbol to be unique. The '$' symbol is fine for all x86/x86_64/arm
and arm64 variants...
Greg
> On Oct 19, 2015, at 11:30 PM
Greg Clayton wrote:
> Yes I have seen a bunch of problems like this on linux due to types being
> incomplete in the debug info (my guess). But I would like to verify that the
> manual DWARF indexing isn't to blame for this. We have great accelerator
> tables that the clang makes for us that actu
Right now there are two ninja check targets: "ninja check-lldb", which
runs dotest and all of the SB API tests, and "ninja check-lldb-unit" which
runs the gtest unit test suite.
I would like to make unit tests run by default. This entails two things,
which could be done independently of each oth
Hi all,
I've been working on a platform-independent system for executables and
shared libraries to export information to debuggers and other software
development tools. It's called Infinity. The initial use case was to
allow GDB to debug multithreaded inferiors without requiring
libthread_db, bu
16 matches
Mail list logo
