Sorry Tong, should have looked more closely at the Python part --- I thought we
were already excluding Python and some of these fell out after that.
RE: this patch or follow up, we don't want a quick check-in that needs a
rework, let's get it right the first time. (I see you're already working
Hm, one of the buildbots is complaining (already fixed it with r218483).
FAIL: AddressSanitizer64 :: TestCases/debug_locate.cc (432 of 21228)
TEST 'AddressSanitizer64 ::
TestCases/debug_locate.cc' FAILED
Script:
--
/home/llvmbb/llvm-build-dir/llvm-clang-ll
Landed in r218481, thanks for review!
http://reviews.llvm.org/D4527
___
lldb-commits mailing list
lldb-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
I think part of our challenge is when we try to build remote pieces with
what is effectively lldb-core, we really could use at least a 2-layer
division of the core. The true low-level goo in a core, and some
higher-level bits that only the lldb client really needs but isn't needed
for a debug stub
I don't have time to look at this right now, but that's an awful lot of #ifndef
__ANDROID__ in places I wouldn't really expect these defines. Particularly the
ones that deal with the IOHandlerEditLine. Either you're building stuff for
llgs that you don't really need to (why does it need the co
LGTM.
We might later want to look at how/where we're constructing IOHandlerEditLine.
It seems like it might first show up at too low a level of the stack based on
your need to comment it out (unneeded in llgs and not wanting to bring in the
libedit dependency).
I'll ping Greg to see if he wan
Handle the case when ParseFrameDescription returns false.
http://reviews.llvm.org/D4527
Files:
include/sanitizer/asan_interface.h
lib/asan/asan_debugging.cc
lib/asan/asan_globals.cc
lib/asan/asan_interface_internal.h
lib/asan/asan_report.cc
lib/asan/asan_report.h
test/asan/TestCases
Author: tfiala
Date: Thu Sep 25 17:12:33 2014
New Revision: 218470
URL: http://llvm.org/viewvc/llvm-project?rev=218470&view=rev
Log:
gtest: remove recursive make, add python driver + Xcode error hook-up.
This change does the following:
* Removes the gtest/Makefile recursive-make-based calling str
Haha okay, jinx :-)
http://reviews.llvm.org/D5495
___
lldb-commits mailing list
lldb-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
>>! In D5495#4, @tfiala wrote:
> Just to clarify for others and give context, Tong:
>
> These are changes that allow llgs to build, within the AOSP source tree,
> using the Android.mk build system, when using the llvm/clang/lldb git repos
> from AOSP replaced with the experimental ones in
> git
> These are changes that allow llgs to build, within the AOSP source tree,
> using the Android.mk build system, when using the llvm/clang/lldb git repos
> from AOSP replaced with the experimental ones in
> github.com/tfiala/aosp-{llvm,clang,lldb}. Is that right, Tong?
Missed one - and aosp-comp
Just to clarify for others and give context, Tong:
These are changes that allow llgs to build, within the AOSP source tree, using
the Android.mk build system, when using the llvm/clang/lldb git repos from AOSP
replaced with the experimental ones in
github.com/tfiala/aosp-{llvm,clang,lldb}. Is
Fixed this up here:
svn commit
Adding gtest
Adding gtest/Makefile
Adding gtest/gtest.xcodeproj
Adding gtest/gtest.xcodeproj/project.pbxproj
Adding gtest/make
Adding gtest/make/Makefile.rules
Adding gtest/unittest
Adding gtest/unittest
Author: tfiala
Date: Thu Sep 25 14:25:07 2014
New Revision: 218460
URL: http://llvm.org/viewvc/llvm-project?rev=218460&view=rev
Log:
Fixup gtest layout, add Linux ThreadStateCoordinator.cpp.
This change does the following:
* Remove test/c++/...
* Add gtest.
* Add gtest/unittest directory for unit
> Yeah, took me a minute to sort that out since the Python package that the
regular testsuite uses is called "unittest"...
A, ok. Yeah I didn't even consider that. I'm not too worried about
confusion there. I'm expecting this will be a relatively low-traffic
directory, and it's scoped to gt
BTW I'll have that fixed up and checked in soon, I'm just fixing a couple
issues with build directory changes and getting it hooked into Xcode.
On Thu, Sep 25, 2014 at 10:43 AM, Todd Fiala wrote:
> > Yeah, took me a minute to sort that out since the Python package that
> the regular testsuite us
Right - that was the reason I wanted the "unittest" level.
I'm trying this scheme out now.
On Thu, Sep 25, 2014 at 9:47 AM, wrote:
> I don't know what kinds of tests you are going to write. If they are all
> 1-1 test->source file, this seems a reasonable scheme. Then if you have
> other tests
> Any thoughts on the structure underneath gtest?
One idea is, for the case of unittests, where the goal is to directly test
class functionality:
gtest/unittest/{MIRROR_lldb_source_path_to_class_dir}
e.g. for the new source/Plugins/Process/Linux/ThreadStateCoordinator.cpp:
gtest/unittest/Plugin
> Maybe it would be better to make a parallel gtest directory, so the
unittest2 framework crawler doesn't accidentally find its way into any of
these tests.
I'm expecting we'll push things around a bit. gtest at the top level
sounds reasonable to me.
> Also, can you think of a better outer direc
19 matches
Mail list logo
