labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
I was building up to this, but I guess you beat me to it. :)
https://reviews.llvm.org/D30559
___
lldb-commits mailing list
lldb-commits@lists.llv
ravitheja updated this revision to Diff 90461.
ravitheja added a comment.
Herald added a subscriber: mgorny.
Changes according to the comments.
https://reviews.llvm.org/D29581
Files:
include/lldb/API/LLDB.h
include/lldb/API/SBDefines.h
include/lldb/API/SBError.h
include/lldb/API/SBProce
ravitheja added inline comments.
Comment at: include/lldb/API/SBProcess.h:269
+ lldb::user_id_t StartTrace(SBTraceOptions &sboptions, lldb::SBError &sberror,
+ lldb::tid_t thread_id = LLDB_INVALID_THREAD_ID);
+
clayborg wrote:
> Shoul
labath added a comment.
I like the free-standing function approach a lot.
https://reviews.llvm.org/D30560
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL296868: Made GetClangTargetCPU() const. (authored by labath).
Changed prior to commit:
https://reviews.llvm.org/D30515?vs=90255&id=90467#toc
Repository:
rL LLVM
https://reviews.llvm.org/D30515
Files
Author: labath
Date: Fri Mar 3 07:35:49 2017
New Revision: 296868
URL: http://llvm.org/viewvc/llvm-project?rev=296868&view=rev
Log:
Made GetClangTargetCPU() const.
Summary:
It does not change members or call non-const members.
HostInfo::GetArchitecture() returns a const object ref (maybe others?
Author: labath
Date: Fri Mar 3 07:49:34 2017
New Revision: 296869
URL: http://llvm.org/viewvc/llvm-project?rev=296869&view=rev
Log:
testsuite/android: build test executables with the android ndk directly
Summary:
This teaches the test makefiles about the Android NDK, so we are able to
run the te
Author: labath
Date: Fri Mar 3 07:49:38 2017
New Revision: 296870
URL: http://llvm.org/viewvc/llvm-project?rev=296870&view=rev
Log:
test: shorten test trace file names
Make sure we don't generate extremely long file names for test trace log
file, as this can cause path-too-long errors. As the co
This revision was automatically updated to reflect the committed changes.
Closed by commit rL296869: testsuite/android: build test executables with the
android ndk directly (authored by labath).
Changed prior to commit:
https://reviews.llvm.org/D30410?vs=89890&id=90470#toc
Repository:
rL LLV
It works because we already require GnuWin32 (even just to run make at all)
On Fri, Mar 3, 2017 at 6:02 AM Pavel Labath via Phabricator via
lldb-commits wrote:
> This revision was automatically updated to reflect the committed changes.
> Closed by commit rL296869: testsuite/android: build test ex
labath added a comment.
Comment at: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:3766-3776
+ llvm::SmallVector signals_to_ignore;
+ int32_t signo = m_unix_signals_sp->GetFirstSignalNumber();
+ while (signo != LLDB_INVALID_SIGNAL_NUMBER) {
+bool should_ignore =
labath created this revision.
Herald added a subscriber: srhines.
building executables with the NDK clang requires -target and
-gcc-toolchain arguments.
https://reviews.llvm.org/D30574
Files:
packages/Python/lldbsuite/test/make/Android.rules
packages/Python/lldbsuite/test/make/Makefile.rule
Author: labath
Date: Fri Mar 3 10:29:56 2017
New Revision: 296876
URL: http://llvm.org/viewvc/llvm-project?rev=296876&view=rev
Log:
Android.rules: fix building on windows
$(realpath), which I guess is a make builtin, gives strange results on
Windows. $(shell realpath) invokes the gnuwin external
Author: labath
Date: Fri Mar 3 11:03:46 2017
New Revision: 296885
URL: http://llvm.org/viewvc/llvm-project?rev=296885&view=rev
Log:
Android.rules: fix building on mac
realpath is not available as an executable on mac. I give up, I am just
going to leave the path with ..'s in it.
Modified:
l
jingham added a comment.
Yes, that is a good solution. It's still a little awkward that DataExtractors
live in Utility and their dumper lives in Core. Especially as almost all the
functionality of the dumper could live in Utility. If you were serious about
using Utility separate from Core yo
Yea, I can see splitting the target specific stuff into a separate "target
aware" dump function and having the base one not require the exeuction
context and go in Utility. In the interest of not breaking anything it
seems reasonable to try to do that as a separate patch so we the functional
and n
jingham added a comment.
That still seems wrong to me. The UnixSignals class manages the data about
signal state including how to respond to them, so it should be the class that
comprehends that data. The mental exercise of "if I had to do this in another
place, would I have to duplicate an a
That sounds right. Please do fix the function names. We can have another
discussion about naming at some point, but we shouldn't do it piecemeal.
Jim
> On Mar 3, 2017, at 9:53 AM, Zachary Turner wrote:
>
> Yea, I can see splitting the target specific stuff into a separate "target
> aware" d
jingham added a comment.
Greg is taking a couple of weeks off between jobs, so he may not get to this
right away. But it should wait on his approval since he had substantial
comments.
I'm pretty sure Kate isn't doing any work on lldb these days, I wouldn't wait
on her to review patches.
htt
Author: zturner
Date: Fri Mar 3 14:21:59 2017
New Revision: 296906
URL: http://llvm.org/viewvc/llvm-project?rev=296906&view=rev
Log:
[Windows] Remove the #include hack.
Prior to MSVC 2015 we had to manually include this header any
time we were going to include or due to a
bug in MSVC's STL im
This revision was automatically updated to reflect the committed changes.
Closed by commit rL296910: Isolate Target-specific functionality of
DataExtractor. (authored by zturner).
Changed prior to commit:
https://reviews.llvm.org/D30560?vs=90432&id=90526#toc
Repository:
rL LLVM
https://revi
Author: zturner
Date: Fri Mar 3 16:40:46 2017
New Revision: 296920
URL: http://llvm.org/viewvc/llvm-project?rev=296920&view=rev
Log:
Add a script to dump out all project inter-dependencies.
Added:
lldb/trunk/scripts/analyze-project-deps.py
Added: lldb/trunk/scripts/analyze-project-deps.py
U
Author: spyffe
Date: Fri Mar 3 17:13:30 2017
New Revision: 296924
URL: http://llvm.org/viewvc/llvm-project?rev=296924&view=rev
Log:
Fixed repo.py to not send git errors to stderr.
Some repos are not git repos, so git is expected
to fail. These errors should not go to stderr,
because Xcode inte
Author: penryu
Date: Fri Mar 3 17:17:29 2017
New Revision: 296925
URL: http://llvm.org/viewvc/llvm-project?rev=296925&view=rev
Log:
Fix Darwin failures introduced in r296909
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL:
http://
Thanks Tim!
I have a few more file moves coming up as well, sorry for the trouble!
On Fri, Mar 3, 2017 at 3:29 PM Tim Hammerquist via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: penryu
> Date: Fri Mar 3 17:17:29 2017
> New Revision: 296925
>
> URL: http://llvm.org/viewvc/llvm-p
I can fix that, I didn't see it in my tests because it doesn't compile that
file on Windows. I'll get a fix in shortly.
On Fri, Mar 3, 2017 at 3:38 PM Tim Hammerquist
wrote:
> Sure, Zachary. I try to step in when I can.
>
> Now that you mention it, your r296910 (DumpDataExtractor) patch is
> br
Yeah, looks like you need to keep DumpHexBytes in DumpDataExtractor. That's a
little weird because it doesn't actually take a DataExtractor, but...
Jim
> On Mar 3, 2017, at 3:45 PM, Zachary Turner via lldb-commits
> wrote:
>
> I can fix that, I didn't see it in my tests because it doesn't co
Yea, it was a static method of DataExtractor before. I noticed the same
thing when i saw it wasn't using any methods of DataExtractor. Oops!
Anyway since this is no less weird than before I'll leave it this way for
now until we figure out something better.
On Fri, Mar 3, 2017 at 3:46 PM Jim Ingh
I guess you could fudge by changing DumpDataExtractor.h to DataDumper.h to
indicate that it is more general than just data extractors.
Jim
> On Mar 3, 2017, at 3:48 PM, Zachary Turner wrote:
>
> Yea, it was a static method of DataExtractor before. I noticed the same
> thing when i saw it was
Author: zturner
Date: Fri Mar 3 17:52:09 2017
New Revision: 296930
URL: http://llvm.org/viewvc/llvm-project?rev=296930&view=rev
Log:
Fix DataExtractor failures.
Some code that doesn't get compiled on Windows had some references
that needed updating, and I missed those.
Modified:
lldb/trunk/
Is that still failing? Extractor.dump(...) should be replaced by
DumpDataExtractor(Extractor, ...) and then everything will work
On Fri, Mar 3, 2017 at 4:29 PM Tim Hammerquist
wrote:
> Hi Zachary!
>
> Thank you for your prompt attention!
>
> I notice you added DumpHexBytes() back, but Dump() is
I'll get this working, but in the future when you are making changes of this
sort please chase down all the instances of functions you are changing, even in
files you aren't building locally. There might be a use that your conversion
doesn't handle, and you don't want to find that out after you'
I usually do this, like when I'm changing #includes I do grep / replace.
In this case it was a little tricky because a name liked Dump is so common
that if my code doesn't compile it, I might not catch it. (Granted, I
should have caught DumpHexBytes, not sure how I missed that one).
On Fri, Mar 3
Yeah, you could have grepped (is that how you spell that?) for "#include
"lldb/Core/DataExtractor.h" then looked at any Dump method in the files that
turned up. That would have reduced the noise.
Ah, staircase wit...
Jim
> On Mar 3, 2017, at 4:46 PM, Zachary Turner wrote:
>
> I usually do t
Might also be useful to have a list of "files only compiled on platform X"
somewhere. Then in this sort of case, you could compile, then scrutinize
carefully all the files in the "not my platform list."
Jim
> On Mar 3, 2017, at 4:51 PM, Jim Ingham via lldb-commits
> wrote:
>
> Yeah, you c
Author: jingham
Date: Fri Mar 3 19:15:24 2017
New Revision: 296938
URL: http://llvm.org/viewvc/llvm-project?rev=296938&view=rev
Log:
Fix the macOS build all the way after r296909.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
lldb/trunk/source/Plugins/Process/MacOSX-Kernel/Communic
Author: zturner
Date: Fri Mar 3 19:28:55 2017
New Revision: 296941
URL: http://llvm.org/viewvc/llvm-project?rev=296941&view=rev
Log:
Move UUID from Core -> Utility.
Added:
lldb/trunk/include/lldb/Utility/UUID.h
lldb/trunk/source/Utility/UUID.cpp
Removed:
lldb/trunk/include/lldb/Core/
Author: zturner
Date: Fri Mar 3 19:30:38 2017
New Revision: 296944
URL: http://llvm.org/viewvc/llvm-project?rev=296944&view=rev
Log:
Add dependency on DynamicLoaderStatic to Utility.
Modified:
lldb/trunk/source/Plugins/DynamicLoader/Static/CMakeLists.txt
Modified: lldb/trunk/source/Plugins/
Author: zturner
Date: Fri Mar 3 19:31:06 2017
New Revision: 296946
URL: http://llvm.org/viewvc/llvm-project?rev=296946&view=rev
Log:
Delete LLDB's code for getting / setting thread name.
This is now functionality in LLVM, and all callers have
already been updated to use the LLVM functions.
Remo
Author: zturner
Date: Fri Mar 3 19:31:29 2017
New Revision: 296947
URL: http://llvm.org/viewvc/llvm-project?rev=296947&view=rev
Log:
Fix a bug in the dep analysis script.
It wasn't always normalizing slashes correctly, so you'd end
up with the same thing in the map twice.
Modified:
lldb/tru
This change seems to have lost the code that would make sure that on platforms
with short thread names we pick up the end of the name passed in because that
is generally the more specific part. Was that just an oversight?
Jim
> On Mar 3, 2017, at 5:31 PM, Zachary Turner via lldb-commits
> wr
Author: spyffe
Date: Fri Mar 3 19:48:43 2017
New Revision: 296951
URL: http://llvm.org/viewvc/llvm-project?rev=296951&view=rev
Log:
Disable the lldb-mi tests on remote platforms.
Currently on remote platforms the lldb-mi tests fail, which means they time out.
Given how many of the lldb-mi tests
Yes, that was an oversight. Which platforms was this on?
On Fri, Mar 3, 2017 at 5:54 PM Jim Ingham wrote:
> This change seems to have lost the code that would make sure that on
> platforms with short thread names we pick up the end of the name passed in
> because that is generally the more specif
I can add this back tonight. I'll do it on the llvm side so no changes
required on lldb side
On Fri, Mar 3, 2017 at 6:01 PM Zachary Turner wrote:
> Yes, that was an oversight. Which platforms was this on?
> On Fri, Mar 3, 2017 at 5:54 PM Jim Ingham wrote:
>
> This change seems to have lost the c
It was done on all platforms, but the way it worked before was there was a
HostInfo::GetMaxThreadNameLength that was the length passed into SetThreadName,
and then the string was back trimmed to that length generically in
ThisThread::SetName.
You can see the length passed in in
HostNativeThrea
eugene updated this revision to Diff 90563.
eugene added a comment.
Herald added a subscriber: mgorny.
Moved signal filtering to UnixSignals and added unit tests for UnixSignals
class.
https://reviews.llvm.org/D30520
Files:
include/lldb/Target/Process.h
include/lldb/Target/UnixSignals.h
46 matches
Mail list logo
