nitesh.jain updated this revision to Diff 93130.
nitesh.jain added a comment.
Update diff as per suggestion.
Thanks
https://reviews.llvm.org/D31280
Files:
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
packages/Python/lldbsuite/test/functionalities/po
fjricci abandoned this revision.
fjricci added a comment.
I primarily wrote this because `getArchFlag()` accounts for the possibility
that `getCompiler()` can be None. But my problem was unrelated, so I don't need
this (and I agree that it would be surprising if anyone did).
https://reviews.ll
clayborg accepted this revision.
clayborg added a comment.
Looks good
https://reviews.llvm.org/D31280
___
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.
The idea here seems fine, but why does StackFrame have to know the magic
$$dereference$$? Why can't it call the Dereference on the synthetic value?
https://reviews.llvm.org/D3136
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.
This test compiles correctly on Darwin if you pass the --std=c++11 flag.
lldbtest has a getstdFlag that returns the correct std value in this case. Can
you get the test running o
Author: jingham
Date: Mon Mar 27 14:03:11 2017
New Revision: 298874
URL: http://llvm.org/viewvc/llvm-project?rev=298874&view=rev
Log:
Fix the Xcode project for OpenBSD additions.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL:
htt
beanz updated this revision to Diff 93165.
beanz added a comment.
Fleshed out the unit test logic to be more meaningful.
https://reviews.llvm.org/D31357
Files:
tools/debugserver/source/CMakeLists.txt
tools/debugserver/source/MacOSX/CMakeLists.txt
unittests/CMakeLists.txt
unittests/debug
Author: jingham
Date: Mon Mar 27 14:12:25 2017
New Revision: 298876
URL: http://llvm.org/viewvc/llvm-project?rev=298876&view=rev
Log:
In FileSpec::Equal, short-cut GetNormalizedPath.
GetNormalizedPath seems to be slow, so it's worth
shortcutting it if possible. This change does so
when the filen
jingham added a comment.
It's a little weird to have the unit tests for debugserver in the top-level
lldb directory. debugserver really is a stand-alone tool that shares no code
with lldb proper. How hard would it be to put the tests under debugserver?
https://reviews.llvm.org/D31357
beanz added a comment.
@jingham I put the unit tests at the top because they depend on LLDB's Host
library (at least the current tests do). I'm attempting to write tests which
cover the socket communication between LLDB and debugserver by sending data
between the two using each side of the API.
jingham added a comment.
debugserver only runs on darwin and we have no intentions of using it
elsewhere. lldb-server is the way to do debugserver for new platforms. I
don't think you need the generality provided by host to test debugserver, OTOH,
if using those classes saves you lots of time
tberghammer requested review of this revision.
tberghammer added a comment.
I am trying to compile it with the following command on OSX but I wasn't able
to get it working:
clang -std=c++11 -g -O0 -fno-builtin -arch x86_64 -fno-limit-debug-info
-I$LLVM_ROOT/lldb/packages/Python/lldbsuite/
beanz updated this revision to Diff 93190.
beanz added a comment.
Added a note to the unit test CMake file about why the tests are where they
are. Generally we isolate debugserver from the rest of LLDB, and this comment
explains the breach of isolation.
https://reviews.llvm.org/D31357
Files:
jingham added a comment.
There's no reason you couldn't build the gnu libstdc++ on Darwin. Anyway, if
that's the problem, I'm pretty sure the testsuite has a way to conditionalize
on which stdlib(s) are available. That would be clearer than conditionalizing
on platform.
https://reviews.llvm
EricWF added a comment.
I don't see anything wrong with this, but I only know libc++ and not LLDB.
> libc++'s atomic does not play well with gcc on linux
It should... Can you elaborate on this issue? I suspect this may be a libc++
bug.
https://reviews.llvm.org/D30984
15 matches
Mail list logo
