[Lldb-commits] [PATCH] C++ API tests review request

[Malea, Daniel]

Oops, that's what I get for rushing -- forgot the most important part. It's attached now. Thanks for the notes!

Apply with patch -p0 


Thanks,
Dan

-----Original Message-----
From: Greg Clayton [mailto:gclayton at apple.com] 
Sent: Thursday, May 02, 2013 6:40 PM
To: Malea, Daniel
Cc: lldb-commits at cs.uiuc.edu
Subject: Re: [PATCH] C++ API tests review request

Feel free to send us your sources and we can try them out here. 

Also I did add a TODO note in POSIXThread:

void
POSIXThread::WillResume(lldb::StateType resume_state) {
	// TODO: the line below shouldn't really be done, but
    // the POSIXThread might rely on this so I will leave this in for now
    SetResumeState(resume_state);
}

No one should be directly calling SetResumeState in their thread subclass. This variable is used to organize what actually goes on when a process is resumed. 

For example if a process has 4 threads and it wanted to run, but threads 1 and 3 stopped at breakpoints, it would need to single step over the breakpoint locations. So it would need to step thread 1 and 3 to get past breakpoints, then resume the process. 


The logic that implements the run would do:

thread1.SetResumeState (eStateStepping)
thread2.SetResumeState (eStateSuspended) thread3.SetResumeState (eStateStepping) thread4.SetResumeState (eStateSuspended)
process.Resume()

In the private state run thread, it would implement this command by doing:

thread1.WillResume (eStateStepping)
thread2.WillResume (eStateSuspended)
thread3.WillResume (eStateSuspended)
thread4.WillResume (eStateSuspended)
process.Resume()
process.WaitForStop()
thread1.WillResume (eStateSuspended)
thread2.WillResume (eStateSuspended)
thread3.WillResume (eStateStepping)
thread4.WillResume (eStateSuspended)
process.Resume()
process.WaitForStop()

So the overall run control for the threads can be controlled by mucking with the SetResumeState() of the thread, followed by a resume. The lower level logic will currently break this down into one of 3 things:

1 - run all threads
2 - run a single thread (used for expressions)
3 - step a single thread

So you might want to take a look at POSIXThread::WillResume() and try to just remove this function so that it doesn't muck with the higher level logic for the run control.

Greg


On May 2, 2013, at 2:55 PM, "Malea, Daniel" <daniel.malea at intel.com> wrote:

> Hi all,
> 
> I'm trying to nail down exactly what multithreaded problems there are with the LLDB API, so I wrote some tests that use it via C++. The same stuff could have been done from Python, but I figured since there's so few C++ tests (one that I found "check_public_api_headers") I figured I'd write some to keep things interesting.
> 
> When someone has a moment, could you provide some feedback, as I'm seeing 3 out of 4 tests fail on Linux/Mac OS X - wondering if these are LLDB bugs I'm uncovering, or more likely, that the tests are using the API incorrectly.
> 
> Here's a brief description of what the tests do:
> 
> 
>  1.  Test that a function registered with SBBreakpoint.SetCallback() 
> is called when a breakpoint is hit. -- the function is not invoked  2.  Test that an SBListener registered with a process receives an event.
>  3.  Test that a process retrieved from an SBEvent can be used to 
> query thread/frame information - retrieving thread/frame works ok, but querying a function name does not  4.  Test that a process can be resumed from a thread that did not start it - This one's weird: SBProcess::GetState() returns eStateStopped() but calling Process::Resume() fails with error "process is running".
> 
> Currently, only #2 passes, which is the simplest case. There's a bunch of boiler plate code in there that is not too interesting. The meat of the test logic are in the .cpp files that are prefixed with "test_".
> 
> 
> Thanks a bunch,
> Dan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_api_multithreaded_svn.patch
Type: application/octet-stream
Size: 16327 bytes
Desc: test_api_multithreaded_svn.patch
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20130503/eb526010/attachment.obj>