Skip to content

Conversation

@Sonicadvance1
Copy link
Member

This gets gdbserver working for simpler cases again. Some of the work is working around #3535 not being complete since some of the thread state management is still split between FEXCore and the frontend.

I'm still working on fixing that code, but until then lets at least get gdbserver working again so we can get x86 debugging.

This doesn't behave properly anymore now that thread management was
moved to the frontend.
This will be necessary to have the frontend track when threads are
executing, for gdbserver.
When parsing `comm`, by default it will have a newline which breaks gdb
in some cases. Strip out the whitespace to fix that issue.
Otherwise we won't wait for gdbserver connection
This ensures that gdb switches to the correct thread on fault in a
multithreaded environment.
This allows us to reconstruct an accurate RIP on fault rather than
ending up at the start of the block.
Otherwise some later spin-loops will wait forever.
Don't notify already paused threads. This causes some weird races.
We can't currently guarantee this condition_variable is always unlocked
without more major refactoring. This was causing GDB to wait forever.
Copy link
Member

@neobrain neobrain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for looking into the problem! It seems that I still can't do anything useful with gdb-multiarch connecting to FEXLoader -G .... Is there anything specifically that should be working now that I can test?

Otherwise, looks like this PR adds a few similarly named interfaces to already sparely documented APIs. That should be sorted out to keep the interfaces somewhat accessible.

void Run();
void Step();
void Stop(bool IgnoreCurrentThread = false);
void Pausing(FEXCore::Core::InternalThreadState* Thread);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the difference between this and "Pause"?

uint64_t HostPC {};
FEXCore::Core::InternalThreadState* Thread {};
};
ThreadBreakEventInfoStruct ThreadBreakEventInfo {};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using std::optional here is more explicit than setting Thread to nullptr. That also protects us against precondition violations, such as if we accidentally read this state when not at a breakpoint.


private:
void Break(int signal);
void BreakThread(FEXCore::Core::InternalThreadState* Thread, int signal);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the difference between this and Break?

void StopThread(FEXCore::Core::InternalThreadState* Thread);
void RunThread(FEXCore::Core::InternalThreadState* Thread);

void RunPrimaryThread(FEXCore::Context::Context* CTX, FEXCore::Core::InternalThreadState* Thread);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the difference between this and "RunThread"?

@Sonicadvance1 Sonicadvance1 marked this pull request as draft June 4, 2024 21:38
@Sonicadvance1
Copy link
Member Author

Pulled a couple minor patches from this in to #4170, but none of the bigger logic changes.
Will be changing enough code that this won't matter much now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants