Author: jingham
Date: Thu Mar 30 20:32:57 2017
New Revision: 299147
URL: http://llvm.org/viewvc/llvm-project?rev=299147&view=rev
Log:
Don't add a newline if the object description already has one.
Modified:
lldb/trunk/source/DataFormatters/ValueObjectPrinter.cpp
Modified: lldb/trunk/source
eugene marked 4 inline comments as done.
eugene added a comment.
> I think we should do some performance measurements to see whether this needs
> more optimising or it's fine as is.
>
> I propose the following benchmark:
>
> bin/lldb bin/clang
>
> make sure clang is statically linked
> br
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
Looks good.
https://reviews.llvm.org/D31485
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/l
krytarowski added a comment.
Thanks! I noted that I introduced some bugs.. but I will fix them in future
revisions. I will move on to threads now. FPR/watchpoints will be done later,
on the cost on adding some code for cores and helping out with base system work.
LLDB/NetBSD is now out of the b
eugene updated this revision to Diff 93572.
eugene added a comment.
Addressing code-review comments.
Most notable change: MethodName::Parse() tries simple version of name parser,
before invoking full power of CPlusPlusNameParser. It really helps with the
perf.
https://reviews.llvm.org/D31451
xiaobai marked an inline comment as done.
xiaobai added inline comments.
Comment at:
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp:1506-1510
+ // We got an invalid address range back
+ if (!region_info.GetRange().IsValid()) {
+error.SetErro
xiaobai updated this revision to Diff 93566.
xiaobai added a comment.
Added unit tests for the method and changed the logic according to clayborg's
suggestion.
https://reviews.llvm.org/D31485
Files:
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
unittests/Process/gdb-re
On Thu, Mar 30, 2017 at 10:47:39PM +0200, Michał Górny wrote:
> On czw, 2017-03-30 at 21:37 +0200, Joerg Sonnenberger wrote:
> > On Thu, Mar 30, 2017 at 06:00:15PM +, Chris Bieneman via Phabricator
> > wrote:
> > > ExecutionEngine headers directly reference symbols from RuntimeDyld,
> > > so w
Author: penryu
Date: Thu Mar 30 16:27:51 2017
New Revision: 299116
URL: http://llvm.org/viewvc/llvm-project?rev=299116&view=rev
Log:
add NetBSD files to Xcode project to resolve failure from r299109
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj/proje
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
Simple logic change so we don't check the range validity more than once.
Comment at:
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp:1506-15
On czw, 2017-03-30 at 13:55 -0700, Chris Bieneman wrote:
> I had a talk with Lang about the ExecutionEngine library structuring, and it
> sounds like there are some problems there that need to be worked out.
>
> Luckily for this specific case, I think the solution is actually quite simple:
>
> `
I had a talk with Lang about the ExecutionEngine library structuring, and it
sounds like there are some problems there that need to be worked out.
Luckily for this specific case, I think the solution is actually quite simple:
```
diff --git a/include/llvm/ExecutionEngine/ExecutionEngine.h
b/inc
On czw, 2017-03-30 at 21:37 +0200, Joerg Sonnenberger wrote:
> On Thu, Mar 30, 2017 at 06:00:15PM +, Chris Bieneman via Phabricator
> wrote:
> > ExecutionEngine headers directly reference symbols from RuntimeDyld,
> > so we should enforce a requirement that anyone using ExeuctionEngine
> > als
Author: kamil
Date: Thu Mar 30 15:25:29 2017
New Revision: 299109
URL: http://llvm.org/viewvc/llvm-project?rev=299109&view=rev
Log:
Battery of NetBSD support improvements
Summary:
Include initial support for:
- single step mode (PT_STEP)
- single step trap handling (TRAP_TRACE)
- exec() trap (
Thanks.
Jim
> On Mar 30, 2017, at 1:16 PM, Tamas Berghammer wrote:
>
> Created bug for exposing ValueObject::Clone as SB API:
> http://bugs.llvm.org/show_bug.cgi?id=32477
>
> On Thu, Mar 30, 2017 at 1:04 PM Jim Ingham via Phabricator
> wrote:
> jingham accepted this revision.
> jingham added
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
MacOS hasn't shipped with gcc for a while now. If you were serious about using
gcc & its STL implementation you would install your own copies of the tools &
libraries. So what's on the sys
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
Thank you. Keep up the good work.
Repository:
rL LLVM
https://reviews.llvm.org/D31450
___
lldb-commits mailing list
lldb-commits@lists.llvm.or
Created bug for exposing ValueObject::Clone as SB API:
http://bugs.llvm.org/show_bug.cgi?id=32477
On Thu, Mar 30, 2017 at 1:04 PM Jim Ingham via Phabricator <
revi...@reviews.llvm.org> wrote:
> jingham accepted this revision.
> jingham added a comment.
> This revision is now accepted and ready to
tberghammer added a comment.
I tried it out on OSX and the problem is that version of libstdc++ shipping
with every recent OSX version (don't know about old ones) is 4.2.1 (last
version with GPL v2) what doesn't support std::unique_ptr (supported since
4.3). Because of this I think the correct
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
Good.
https://reviews.llvm.org/D31371
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/
I see. Might be worth filing an enhancement request to expose Clone so you can
do this in a Python synthetic child provider. But there's no reason that lack
should block this change.
Jim
> On Mar 30, 2017, at 12:51 PM, Tamas Berghammer wrote:
>
> It is possible to vend one of the actual bac
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
Excellent!
https://reviews.llvm.org/D31368
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/list
tberghammer updated this revision to Diff 93529.
tberghammer added a comment.
Fix grammer for the html documentation.
https://reviews.llvm.org/D31368
Files:
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/TestDataFormatterStdUniquePtr.py
tberghammer updated this revision to Diff 93528.
tberghammer added a comment.
Fix typos in the comments
https://reviews.llvm.org/D31371
Files:
include/lldb/Core/ValueObject.h
source/Core/ValueObject.cpp
source/DataFormatters/VectorType.cpp
source/Plugins/Language/CPlusPlus/LibCxxMap.cpp
It is possible to vend one of the actual backing object as a synthetic
child using the SB API. What is not possible from the SB API at the moment
(we might want to fix it) is to vend one of the actual backing object with
a different name then the underlying object itself. You can still say that
obj
krytarowski added a comment.
Thanks!
Repository:
rL LLVM
https://reviews.llvm.org/D31450
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.
One grammar comment in the docs, and then this is good.
Comment at: www/varformats.html:1071
[3] This method is optional (starting with SVN revision 219330).
Th
jingham resigned from this revision.
jingham added a comment.
Kyril, I haven't been involved in the lldb-server parts of lldb. Greg sketched
out those interfaces and mostly folks working on Windows & Linux have fleshed
them out. I haven't been following the design discussions for lldb-server,
tberghammer updated this revision to Diff 93525.
tberghammer added a comment.
Add documentation to the website
https://reviews.llvm.org/D31368
Files:
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libstdcpp/unique_ptr/TestDataFormatterStdUniquePtr.py
sourc
On Thu, Mar 30, 2017 at 06:00:15PM +, Chris Bieneman via Phabricator wrote:
> ExecutionEngine headers directly reference symbols from RuntimeDyld,
> so we should enforce a requirement that anyone using ExeuctionEngine
> also link RuntimeDyld. This works today as expected for static archive
> bu
krytarowski updated this revision to Diff 93524.
krytarowski added a comment.
Herald added a subscriber: srhines.
Apply changes from review. No visible regressions in "check-lldb".
Repository:
rL LLVM
https://reviews.llvm.org/D31450
Files:
source/Host/common/Host.cpp
source/Plugins/Dynam
mgorny added a comment.
In https://reviews.llvm.org/D31367#714305, @beanz wrote:
> Please revert your patch. It is *not* the right solution and is masking
> underlying problems.
Reverted in r299095. Now I'd really appreciate some help in figuring out how to
fix it properly.
> ExecutionEngine
Author: mgorny
Date: Thu Mar 30 13:24:07 2017
New Revision: 299095
URL: http://llvm.org/viewvc/llvm-project?rev=299095&view=rev
Log:
Revert r298776 - Expression: add missing linkage to RuntimeDyld ...
This needs to be addressed within LLVM itself.
Modified:
lldb/trunk/source/Expression/CMake
beanz added a comment.
Please revert your patch. It is *not* the right solution and is masking
underlying problems.
ExecutionEngine headers directly reference symbols from RuntimeDyld, so we
should enforce a requirement that anyone using ExeuctionEngine also link
RuntimeDyld. This works today
beanz added a comment.
This is definitely not the right fix. Please revert.
ExecutionEngine's LLVMBuild.txt file explicitly lists that RuntimeDyld is a
required library of ExecutionEngine (as well as a few others). LLVM's CMake
should be connecting that as an explicit dependency, and for some r
labath added a comment.
I cant help but feel that this could have been done in a simpler way, but then
again, some of the cases you have dug up are quite tricky.
I think we should do some performance measurements to see whether this needs
more optimising or it's fine as is.
I propose the follo
labath added a comment.
The additional check sounds fine. There's a test for this class in
unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp where you can
add a test for this behavior.
https://reviews.llvm.org/D31485
___
lldb-commi
mgorny added a comment.
In https://reviews.llvm.org/D31367#713472, @labath wrote:
> We don't depend on the RuntimeDyld component of llvm directy -- we only use
> it indirectly through the ExecutionEngine component. Shouldn't that be
> reflected as a dependency in the build system somehow, so th
38 matches
Mail list logo
