-
Notifications
You must be signed in to change notification settings - Fork 333
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[lldb] Introduce command to select task "threads" #9840
base: stable/20240723
Are you sure you want to change the base?
[lldb] Introduce command to select task "threads" #9840
Conversation
@swift-ci test |
Shouldn't this go on the stable branch instead? |
Yes, I will update it shortly (I was waiting first to commit #9845) |
8fd2cbc
to
b81995b
Compare
367ecb2
to
d32d287
Compare
Now updated to stable. |
@swift-ci test |
On darwin it's "0x0002" but on linux it's "2".
@swift-ci test linux |
@swift-ci test linux |
1 similar comment
@swift-ci test linux |
@swift-ci test linux |
1 similar comment
@swift-ci test linux |
frame_index = frame.idx | ||
self.assertNotEqual(frame_index, -1) | ||
|
||
self.expect( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would feel better about this test if it would use the SBAPI instead of matching for the precise formatting of the frame rendering. Otherwise we'll need to update this every tome some changes the UI upstream.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
something like getting the current frame from the current thread and checking SBFrame::GetFunctionName() etc ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
// GetStatus prints the backtrace. | ||
thread_task.get()->GetStatus(result.GetOutputStream(), 0, UINT32_MAX, 0, | ||
false, true); | ||
auto &thread_list = m_exe_ctx.GetProcessRef().GetThreadList(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Process class has a mutex to protect its thread list; should we lock it here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question. The ThreadList references the processes lock. The lock is taken inside AddThread
, I would say there's no need to take the lock here explicitly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I wasn't aware that these methods were already thread-safe.
I guess the only argument for locking outside would be if these two operations need to be atomic:
thread_list.AddThread(thread_task.get());
thread_list.SetSelectedThreadByID(thread_task.get()->GetID())
If they don't, then no locking is needed
@swift-ci test |
@swift-ci test |
Introduce
language swift task select <task>
. This uses much of the work done fortask backtrace
, including the artificial thread classThreadTask
.This change allows users to select a task, as though it is a thread. From there, they can run other thread commands, such as
backtrace
. Users can also then run frame navigation commands, such asup
/down
/frame select
.