sas added a comment.
Putting that check in an inline function instead of doing ad-hoc validation in
the call-site seems better indeed.
https://reviews.llvm.org/D35036
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/c
penryu added a comment.
Thanks, sas.
I'll be honest, my prefer solution involves an inlined function (uint64_t ->
TypeCodes) that eliminates the cast from the NSNumberSummaryProvider() method
altogether. This way we can handle any dirty mappings from raw memory directory
to the enum within the
sas accepted this revision.
sas added a comment.
This revision is now accepted and ready to land.
Looks like the numeric values of `TypeCode` are contiguous. It would probably
be cleaner to a check after the cast to validate the value instead of having to
add a line for each label in the `switch
dlj added a comment.
In https://reviews.llvm.org/D34853#798699, @andrewng wrote:
> Hi,
>
> I believe that this "build mode" is intended for the Visual Studio MSVC
> build. This build is special in that it can produce builds for multiple
> configurations, e.g. Debug, Release & RelWithDebInfo, wi
Author: jingham
Date: Wed Jul 5 19:18:16 2017
New Revision: 307234
URL: http://llvm.org/viewvc/llvm-project?rev=307234&view=rev
Log:
Add a lldbutils routine that gathers up the boiler-plate
to make a target, set a source regex breakpoint, run to
the breakpoint and find the thread that hit the br
Author: penryu
Date: Wed Jul 5 17:08:54 2017
New Revision: 307228
URL: http://llvm.org/viewvc/llvm-project?rev=307228&view=rev
Log:
add googlemock include dir to lldb-gtest Xcode target
Add the googlemock include directory from LLVM to CFLAGS arguments in
Xcode's lldb-gtest.
Modified:
lld
penryu created this revision.
Testing the value of type_code against the closed enum TypeCodes
provides statically verifiable completeness of testing. However, one
branch assigns to type_code by casting directly from a masked integer
value. This is currently handled by adding a default: case after
clayborg added inline comments.
Comment at: source/Utility/StringExtractorGDBRemote.cpp:467
+if (str_index != std::string::npos)
+ error_messg = m_packet.substr(++str_index);
+
clayborg wrote:
> hex encode
There is also a hex decode that will need to be
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
See inlined comments.
Comment at:
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp:3176
+ EnableErrorStringInPacket();
StreamGDBRemote
kubamracek added a comment.
Landed in r307170.
https://reviews.llvm.org/D34774
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: kuba.brecka
Date: Wed Jul 5 09:29:36 2017
New Revision: 307170
URL: http://llvm.org/viewvc/llvm-project?rev=307170&view=rev
Log:
[lldb] Add a testcase for MainThreadCheckerRuntime plugin
This adds a simple testcase for MainThreadCheckerRuntime. The tool (Main Thread
Checker) is only ava
clayborg added a comment.
In https://reviews.llvm.org/D33035#799404, @abhishek.aggarwal wrote:
> In https://reviews.llvm.org/D33035#799058, @clayborg wrote:
>
> > So std::vector shouldn't be used in a public API. You should make a class
> > that wraps your objects. LLDB's public API has lldb::SB
labath added inline comments.
Comment at:
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp:3176
+ EnableErrorStringInPacket();
StreamGDBRemote escaped_packet;
I don't like how every packet function needs to enable this manually. Every
f
ravitheja updated this revision to Diff 105273.
ravitheja added a comment.
Forgot this in the doc.
https://reviews.llvm.org/D34945
Files:
docs/lldb-gdb-remote.txt
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationCli
ravitheja updated this revision to Diff 105272.
ravitheja added a comment.
Updating Doc and changing feature to be enabled by client.
https://reviews.llvm.org/D34945
Files:
docs/lldb-gdb-remote.txt
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
source/Plugins/Process/g
Author: labath
Date: Wed Jul 5 07:54:46 2017
New Revision: 307161
URL: http://llvm.org/viewvc/llvm-project?rev=307161&view=rev
Log:
Fix assorted compiler warnings (mismatched signedness and printf specifiers)
Modified:
lldb/trunk/source/Commands/CommandObjectThread.cpp
lldb/trunk/source/
Author: labath
Date: Wed Jul 5 07:54:41 2017
New Revision: 307160
URL: http://llvm.org/viewvc/llvm-project?rev=307160&view=rev
Log:
Fix "process load" on new android targets
Summary:
On older android targets, we needed a dlopen rename workaround to get
"process load" working. Since API 26 this i
abhishek.aggarwal added a comment.
In https://reviews.llvm.org/D33035#799058, @clayborg wrote:
> So std::vector shouldn't be used in a public API. You should make a class
> that wraps your objects. LLDB's public API has lldb::SBInstruction and
> lldb::SBInstructionList as examples. std::vector
eugene accepted this revision.
eugene added a comment.
This revision is now accepted and ready to land.
Great change! Thanks making it.
https://reviews.llvm.org/D34911
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/c
karnajitw marked an inline comment as done.
karnajitw added a comment.
With my test setup on i386-*-freebsd-11.0 (freebsd patched).. There seems to be
quite a good improvement in the number of test failures.
[BEFORE lldb patch]
===
Test Result Summary
===
Test M
clayborg added a comment.
So std::vector shouldn't be used in a public API. You should make a class that
wraps your objects. LLDB's public API has lldb::SBInstruction and
lldb::SBInstructionList as examples. std::vector on other systems compiles
differently for debug and release builds and thin
clayborg added a comment.
I would think we would try to enable this using something like:
QEnableErrorStrings
And if the the server responds with "OK" then we know it is enabled. By default
the server should not enable any fancy features without being asked. We would
like lldb-server to stay c
labath added a comment.
In https://reviews.llvm.org/D33035#798925, @abhishek.aggarwal wrote:
> In https://reviews.llvm.org/D33035#798885, @labath wrote:
>
> > Hm... that's a bit of a drag. I guess the SB API never ran into this
> > problem because it always provides it's own vector-like classes
abhishek.aggarwal added a comment.
In https://reviews.llvm.org/D33035#798885, @labath wrote:
> In https://reviews.llvm.org/D33035#798857, @abhishek.aggarwal wrote:
>
> > Hi Pavel .. I could remove all exception handling code from source files.
> > However, I am still wondering how to disable exc
labath added a comment.
In https://reviews.llvm.org/D33035#798857, @abhishek.aggarwal wrote:
> Hi Pavel .. I could remove all exception handling code from source files.
> However, I am still wondering how to disable exception handling while
> providing python functions for C++ APIs of the featu
abhishek.aggarwal added a comment.
Hi Pavel .. I could remove all exception handling code from source files.
However, I am still wondering how to disable exception handling while providing
python functions for C++ APIs of the features. Can you suggest something here?
The whole problem is occurr
abhishek.aggarwal updated this revision to Diff 105163.
abhishek.aggarwal added a comment.
Removed exception handling code
https://reviews.llvm.org/D33035
Files:
tools/CMakeLists.txt
tools/intel-features/CMakeLists.txt
tools/intel-features/README.txt
tools/intel-features/cli-wrapper.cpp
andrewng added a comment.
Hi,
I believe that this "build mode" is intended for the Visual Studio MSVC build.
This build is special in that it can produce builds for multiple
configurations, e.g. Debug, Release & RelWithDebInfo, within the same top level
build output directory. It is this confi
Author: labath
Date: Tue Jul 4 05:29:30 2017
New Revision: 307071
URL: http://llvm.org/viewvc/llvm-project?rev=307071&view=rev
Log:
Fix some warnings in ProcessorTraceTest.cpp
Modified:
lldb/trunk/unittests/Process/Linux/ProcessorTraceTest.cpp
Modified: lldb/trunk/unittests/Process/Linux/Pr
This revision was automatically updated to reflect the committed changes.
Closed by commit rL307072: Update lldb architecture docs (authored by labath).
Repository:
rL LLVM
https://reviews.llvm.org/D34872
Files:
lldb/trunk/www/architecture.html
lldb/trunk/www/architecture/index.html
Index
Author: labath
Date: Tue Jul 4 05:29:34 2017
New Revision: 307072
URL: http://llvm.org/viewvc/llvm-project?rev=307072&view=rev
Log:
Update lldb architecture docs
Summary:
Due to recent refactors, the descriptions of various modules were wildly
out of date. With this patch, I am not trying to leg
ravitheja added a comment.
With this patch, I see the extra packet to query from server is probably
unnecessary. I mean the error code is still there and it should be sufficient
for the client to detect an error. As long as it does not mistake it for
something else it should not be a problem ?
ravitheja marked 4 inline comments as done.
ravitheja added inline comments.
Comment at:
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp:110
+ packet += ";";
+ packet += std::string(error.AsCString());
+ return SendPacketNoLock(packet);
lab
ravitheja updated this revision to Diff 105150.
ravitheja added a comment.
changes from feedback.
https://reviews.llvm.org/D34945
Files:
docs/lldb-gdb-remote.txt
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClie
labath added a comment.
In https://reviews.llvm.org/D34945#798808, @ravitheja wrote:
> With this patch, I see the extra packet to query from server is probably
> unnecessary. I mean the error code is still there and it should be sufficient
> for the client to detect an error. As long as it does
ravitheja added a comment.
Yeah that would be broken, as long as we make the error packet more than 3
bytes, then it won't work with the older lldb clients.
https://reviews.llvm.org/D34945
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
h
36 matches
Mail list logo
