Author: jingham
Date: Wed May 31 20:05:30 2017
New Revision: 304379
URL: http://llvm.org/viewvc/llvm-project?rev=304379&view=rev
Log:
Forgot to mention rewriting CommandObject::DoExecute
using the SB API's not the lldb_private API's.
Modified:
lldb/trunk/www/projects.html
Modified: lldb/tru
> On May 31, 2017, at 2:02 PM, Zachary Turner wrote:
>
> This hypothetical DSL could still run SB API statements. I don't necessarily
> think it *should*, since what the SB API does and what the commands do are
> very different (for example SBTarget.Create() does something entirely
> differe
And once you start annotating source code with statements, things become
even more concise. For example, you could write the above test:
# input_file: foo.cpp
# int main(int argc, char **argv) { // bp1 = BREAK_HERE
# return 0;// bp2 = BREAK_HERE
# }
# // VERIFY(bp1.hits == 1)
# // VERIFY(
This hypothetical DSL could still run SB API statements. I don't
necessarily think it *should*, since what the SB API does and what the
commands do are very different (for example SBTarget.Create() does
something entirely different than "target create", so you're not actually
testing what the debu
> On May 31, 2017, at 12:22 PM, Zachary Turner wrote:
>
> Writing tests that are
>
> A) as easy as possible to write and understand
I've never understood why you consider the tests in our test case hard to write
or understand. Till I added the example directory, you had to go search around
Writing tests that are
A) as easy as possible to write and understand
B) built on a multiprocessing infrastructure that is battle tested and
known to not be flaky
C) Familiar to other llvm developers, so as to not discourage subject
matter experts from other areas to make relevant improvements to
Before we get past "it's hard" to "just to do it", it would help me to be clear
first on what you are actually trying to achieve with this proposal. It's not
clear to me what problem are people trying to solve here? If it is writing
tests for the decomposable parts of lldb - like the tests Jas
SBThread::Resume instructs lldb to set the resume state on a thread to
"eStateRunning", meaning that means the next time you continue the process,
that thread will get a chance to run. It has no effect on the StopReason for
the thread (it doesn't even start it running except maybe in the not we
zturner added inline comments.
Comment at: source/Plugins/Process/Linux/NativeProcessLinux.cpp:738-742
+StartProcessorTracing(tid, m_pt_process_config, traceMonitor);
+if (traceMonitor.get() != nullptr) {
+ traceMonitor->setUserID(m_pt_process_uid);
+ m_pt_trace
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
Okay, that seems reasonable.
Repository:
rL LLVM
https://reviews.llvm.org/D32732
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
h
zturner added a comment.
In https://reviews.llvm.org/D32930#767820, @beanz wrote:
> One small comment below. In general I agree with the thoughts here, and I
> think that this is a huge step forward for testing the debug server
> components.
>
> I also agree with Zachary in principal that it wo
beanz added inline comments.
Comment at: unittests/tools/CMakeLists.txt:1
+if(UNIX AND NOT APPLE)
+ add_subdirectory(lldb-server)
labath wrote:
> beanz wrote:
> > labath wrote:
> > > This is not what I meant. The only targets (at least until we have
> > > debug
Author: spyffe
Date: Wed May 31 12:18:10 2017
New Revision: 304314
URL: http://llvm.org/viewvc/llvm-project?rev=304314&view=rev
Log:
Added a testcase for local/namespaced name conflicts.
This works on SVN but is a bit fragile on the Swift branch.
I'm adding the test to both, so we have this path
clayborg resigned from this revision.
clayborg added a comment.
I trust Pavel to review this since it is in the Linux native plugins mostly.
https://reviews.llvm.org/D33674
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.
clayborg accepted this revision.
clayborg added a comment.
Looks like a good starting point. Thanks for the changes.
https://reviews.llvm.org/D33426
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/list
labath added a comment.
Thanks for the support, @beanz.
Comment at: unittests/tools/CMakeLists.txt:1
+if(UNIX AND NOT APPLE)
+ add_subdirectory(lldb-server)
beanz wrote:
> labath wrote:
> > This is not what I meant. The only targets (at least until we have
>
labath added a comment.
In https://reviews.llvm.org/D33426#766525, @bgianfo wrote:
> Address Pavel and Greg's feedback on Diff 100365.
>
> Pavel: I took your suggestions to make the test case more readable,
> I really appreciate the guidance. I did have to tweak some of the
> functionality to m
labath added a comment.
In https://reviews.llvm.org/D33035#767029, @abhishek.aggarwal wrote:
> In https://reviews.llvm.org/D33035#754640, @labath wrote:
>
> > I don't really like that we are adding a public shared library for every
> > tiny intel feature. Could we at least merge this "plugin" wi
labath added a comment.
First batch of comments from me, I think I will have some more once I gain more
insight into this. The main one is about the constructor/initialize,
destructor/destroy duality, which we should abolish. The rest is mostly
stylistic.
Comment at: source/
bgianfo updated this revision to Diff 100830.
bgianfo added a comment.
Fix bug in "unique" backtrace output that Greg pointed out.
Introduced a new format for unique frames and plumbed that
through the stacks to be able to toggle between them both
depending on the calling arguments.
https://rev
20 matches
Mail list logo
