Skip to content
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

WebSocket based debugger interface #10909

Merged
merged 45 commits into from
Jun 9, 2018

Conversation

unknownbrackets
Copy link
Collaborator

@unknownbrackets unknownbrackets commented Apr 13, 2018

If you want to try it:

  1. Run this build on your device (Android / iOS / desktop / whatever.)
  2. Enable Settings -> Tools -> Developer tools -> Allow remote debugger.
  3. Go here: http://ppsspp-debugger.unknownbrackets.org/

Alternatively (only logs, no debugger):
Copy this into an HTML file (desktop, whatever): https://gist.github.com/unknownbrackets/385c01ca12a5ac22071f688e84c39ba3 (possibly PPSSPP could embed its own default HTML...)
Open the HTML file in a web browser and play a game: watch the logs roll in.

This is just a thrown-together example and of course command line, lua, whatever could be used to speak to this WebSocket (a list of WebSocket libraries.) I'm planning a simple JSON API.

The debugger would also work fine in a Chrome tab on the device (assuming a mobile friendly debugger UI...) as long as PPSSPP is not quit (which might become the case on iOS...)

-[Unknown]

@@ -161,6 +162,10 @@ static void ExecuteServer() {
http->RegisterHandler(pair.first.c_str(), handler);
}

// TODO: This isn't an ideal place to put this... should separate.
// But kinda nice to only have it listen on one port?
Copy link
Owner

Choose a reason for hiding this comment

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

Yeah, I think this is fine really.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Cool. Thinking of moving it to Core/WebServer.cpp or something, and sending flags to it to restart with remote iso / debugger enabled.

-[Unknown]

@hrydgard
Copy link
Owner

Really cool stuff!

Regarding JSON serializer, we have a simple writer in ext/native/json_writer and a (different) reader in ext/native/ext/vjson. Might be worth using a proper one if we're gonna write a lot of different structs to json though, but I don't know much about which the best one today might be.

Same thing with React etc, not a frontend guy :)

@unknownbrackets
Copy link
Collaborator Author

Okay, just using that json_writer then (totally forgot it existed.) I think it will work fine.

Not sure if anyone else has opinions on frontend or where to source them - ideally this would make hacking, translation, cheat, whatever tools more accessible.

-[Unknown]

@unknownbrackets
Copy link
Collaborator Author

Went ahead and switched from vjson to gason (newer from same author.) Otherwise, vjson would parse 32-bit unsigned integer parameters as either truncated ints or floats.

-[Unknown]

@hrydgard
Copy link
Owner

hrydgard commented Apr 15, 2018

Yeah, gason seems fine. Good stuff. And thanks for fixing stupid bugs in that old json writer, heh.

@weituotian
Copy link

Really cool stuff!

if it is allow, i want Memory::base;╰( ̄▽ ̄)╮

@unknownbrackets
Copy link
Collaborator Author

I'm planning to have memory APIs: read, write, disasm, assemble, and memory breakpoint management.

Are you asking for an API to return the C++ address in Memory::base? Guess I can add that (although it'll only be useful on some platforms, I think.)

-[Unknown]

@unknownbrackets
Copy link
Collaborator Author

unknownbrackets commented Apr 30, 2018

Just a note: at this point the branch supports other platforms (Linux, Android, etc.) but there's no breakpoint support on ARM. That means you can only step into and step HLE on ARM devices at the moment. Actually, I suppose it probably works if you use IR.

It also exposes Memory.base for all your cheat searching needs.

-[Unknown]

@unknownbrackets
Copy link
Collaborator Author

Okay, I've published a somewhat functional debugger UI here:

http://ppsspp-debugger.unknownbrackets.org/

As noted above, x86 only for any breakpointing / step over / step out / etc. You'll need to compile the latest branch here.

-[Unknown]

@unknownbrackets
Copy link
Collaborator Author

Now arm64 has breakpoints. Didn't test memory breakpoints yet, but hopefully they work....

-[Unknown]

This way we can switch context.
Lumping function symbols in here too, they're pretty related...
Ideally get rid of the memory lock...
And now step over/out/into can tie to the correct thread.
These happen on bytes that are not actually code.
@unknownbrackets
Copy link
Collaborator Author

Yep, rebased. I haven't tested these changes with GCC 8 either, though.

-[Unknown]

@hrydgard
Copy link
Owner

hrydgard commented Jun 8, 2018

Well, I guess there will be enough platforms that we can bisect on either way :)

I'll give this a quick read through a little later and then probably merge. Actually, your pull request says "Not ready for merge" still?

@hrydgard
Copy link
Owner

hrydgard commented Jun 9, 2018

@unknownbrackets I'm fine with this. Again, it says "Not ready for merge" in the pull request, so should I or not? :) If you're ready you can go ahead.

@unknownbrackets
Copy link
Collaborator Author

Oops, thanks for checking - forgot to remove it from there.

-[Unknown]

@unknownbrackets unknownbrackets merged commit 9d96e65 into hrydgard:master Jun 9, 2018
@unknownbrackets unknownbrackets deleted the debugger branch June 9, 2018 19:37
@Leopard20
Copy link
Contributor

Leopard20 commented Jun 9, 2018

@unknownbrackets Finally! Let's check this out! :)

Edit: Shoot! Build isn't done yet! 😅

@Leopard20
Copy link
Contributor

Leopard20 commented Jun 9, 2018

@unknownbrackets So...how do I make this work on Android again? I enabled Allow Remote Debugging but when I go to the mentioned site it says it can't connect to PPSSPP. 🤔
Also, is there a way to access the address directly from within the app? Like clicking on it to open the browser to that address or something?

@unknownbrackets
Copy link
Collaborator Author

Hm. That's all that should be needed. Specifically:

  1. Make sure both devices are connected to the same wifi and use NAT (e.g. you have local IPs like 10.x.x.x or 192.168.x.x or 172.16.x.x.)
  2. Make sure Allow Remote Debugging is checked on the device you want to debug (e.g. Android.)
  3. While PPSSPP is running (doesn't need to be in a game yet), open http://ppsspp-debugger.unknownbrackets.org/.

IMPORTANT: https://ppsspp-debugger.unknownbrackets.org/ will not work. It unfortunately CANNOT be SSL because the emulator itself doesn't (and can't really) have a valid SSL certificate.

If this doesn't work, you can try looking at the IP and port your device is using (it can be seen under Tools -> Remote Disc Streaming -> Settings) and type it manually. If you go to http://192.x.x.x:zzzz/ in your browser it should also show a text file with at least one line "/debugger".

If you can't access the ip:port from your PC browser, then it could mean something is blocking the connection (either not the same wifi, or your device has a firewall on it - most Androids don't.) If you can, but the debugger doesn't work, it probably means a bug...

-[Unknown]

@unknownbrackets
Copy link
Collaborator Author

Just wondering - did that help?

Also, I've outlined the missing features for the web debugger UI here:
https://github.com/unknownbrackets/ppsspp-debugger/projects

-[Unknown]

@hrydgard
Copy link
Owner

hrydgard commented Jun 9, 2018

Confirming that it works fine on Android for me if I have the device and the debugger on the same network. If it matters, whatismyip shows only a IPv4 address for me where I am now.

@unknownbrackets
Copy link
Collaborator Author

Ah, yes, it might be a little restrictive for ipv6 currently. It currently assumes the devices will be on the same /64 or "ipv6 subnet", which is commonly the case.

Your internet provider may give you an entire /56, but usually your router will assign IPs within a single /64 ipv6 subnet even so. If the router ends up assigning IPs more liberally and your mobile device and desktop are in entirely different subnets, then the automatic IP detection won't work.

-[Unknown]

@Leopard20
Copy link
Contributor

Leopard20 commented Jun 10, 2018

Derp, forgot about my phone firewall! Now it works! Thanks!

@anr2me
Copy link
Collaborator

anr2me commented Oct 23, 2021

Remote debugging seems to have a low chance to get connected :(
I've been trying to get it connected to "ws://192.168.8.100" by clicking the "Connect Automatically" on many attempts, but can only succeed twice.
And sometimes it gets disconnected by it self while i'm watching the logs from a game.

Or may be it takes a long time for Remote debugging to be ready to accept the connection? like within a minute or two may be?

Btw, i wished i can resize the Log window so i can get better view with many rows visible :)

@unknownbrackets
Copy link
Collaborator Author

If you're using multiple instances, which I'd guess you probably are, that may be impacting it.

"Connect automatically" looks up what IPs and ports have registered with your public IP, and tries to connect to them. But if you use multiple instances, it's probably rotating the port setting for each new instance, and might be causing a bunch of noise.

There's no need to type anything when using connect automatically. If you know your address and the port it's listening on, you can type "ws://192.168.8.100:12345" and connect manually. That field is only used when connecting manually, and must include the port.

I've only had it disconnect on me midway when something crashes or gets disconnected from the network.

-[Unknown]

@anr2me
Copy link
Collaborator

anr2me commented Oct 23, 2021

If you're using multiple instances, which I'd guess you probably are, that may be impacting it.

Nope, i was using one instance on PC and another on Android, and using it to get Android logs (only the one on Android have Remote debugging enabled), in the end i went back to using logcat since the connection is more stable (but the timestamp on Android logcat seems to be delayed by 1 second compared to the timestamp on Windows Logs, which can be confusing to compare)

"Connect automatically" looks up what IPs and ports have registered with your public IP, and tries to connect to them. But if you use multiple instances, it's probably rotating the port setting for each new instance, and might be causing a bunch of noise.

Ah, i didn't know "automatic" uses the public IP

There's no need to type anything when using connect automatically. If you know your address and the port it's listening on, you can type "ws://192.168.8.100:12345" and connect manually. That field is only used when connecting manually, and must include the port.

Since it wasn't clearly stated which port it was using (i assume "ws://" itself identify the port) thus i didn't include the port, so that is probably why the "Connect Manually" never worked, is it supposed to be port 12345?

@unknownbrackets
Copy link
Collaborator Author

The port is shown under the remote disc streaming settings, but it's generated dynamically, it's not a fixed port.

-[Unknown]

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.

5 participants