This is an archive of the discontinued LLVM Phabricator instance.

[Apple Silicon] Rewrite part of the Rosetta support to be confined in Apple specific files
ClosedPublic

Authored by davide on Jun 29 2020, 2:57 PM.

Details

Summary

Nothing crazy here, just an organizational cleanup.

Diff Detail

Event Timeline

davide created this revision.Jun 29 2020, 2:57 PM
davide marked an inline comment as done.Jun 29 2020, 2:59 PM
davide added inline comments.
lldb/include/lldb/Host/Host.h
231

Stale comment, I'll update

davide updated this revision to Diff 274253.Jun 29 2020, 3:00 PM
aprantl added inline comments.Jun 29 2020, 4:48 PM
lldb/include/lldb/Host/Host.h
231

Is this supposed to be a generic function call that, e.g, should fire for debugging a process in QEMU under Linux, or is it meant to specifically check for Rosetta on macOS? The comment makes it sound like it's the latter and the API name hints at the former. It would be nice to clarify this in the comment.

JDevlieghere added inline comments.
lldb/source/Host/macosx/objcxx/Host.mm
1471

nit: static_cast for consistency with line 1468?

1472

nit: nullptr

davide marked an inline comment as done.Jun 29 2020, 7:55 PM
davide added inline comments.
lldb/include/lldb/Host/Host.h
231

It is meant specifically for Rosetta, but this leaves in Host, so I decided for a generic name.
Do you have a better suggestion for the name or the comment ? Happy to go with it

labath added a subscriber: labath.Jun 30 2020, 12:22 AM
labath added inline comments.
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
3424

I don't think this is a particularly good abstraction, as the debugserver path is still left here, and the path is definitely os- and arch-specific. It would be better if the API returned the path to the debugserver-to-be-used instead.

Bonus points if you can also hide the DEBUGSERVER_BASENAME logic from GDBRemoteCommunication.cpp into the same API.

davide marked an inline comment as done.Jun 30 2020, 10:36 AM
davide added inline comments.
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
3424

hmm, I wonder if this code should live in GDBRemoteCommunication.cpp

aprantl added inline comments.Jun 30 2020, 2:34 PM
lldb/include/lldb/Host/Host.h
231

Not awesome, but IsMacOSRosettaProcess or IsMacOSRosettaTranslated?

A more serious question: Is Host actually the right place for this function? What happens when I remote-debug a Rosetta process from another Mac or a Linux machine? Is there even a correct abstraction for this use-case? Platform maybe?

labath added inline comments.Jun 30 2020, 11:38 PM
lldb/include/lldb/Host/Host.h
231

This code is only used when debugging on the host. When debugging remotely, you either connect to at already running instance of debugserver, or you ask the lldb-server-platform process to launch one for you. The platform process then should use this function to find the right debugserver to launch, but using a Host function is appropriate there, because the platform process is running remotely, and so it will the the "remote Host" which is answering the question.

lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
3424

I think it ended up there because the gdb-server launching code is used from both liblldb and lldb-server (the platform version), and GDBRemoteCommunication is the greatest common denominator. It's not ideal, but I don't think its the worst thing that we have. (At one point I'd like to create a library to house code which is shared between liblldb and lldb-server, and then it may be easier to organize things better.)

Speaking of that... I think this code should live in GDBRemoteCommunication as well. In the situation where one is remote-debugging a mac via lldb-server-platform, I assume one would want the platform process to automatically spawn the right debugserver for the rosetta thingies.

aprantl added inline comments.Jul 1 2020, 9:28 AM
lldb/include/lldb/Host/Host.h
231

When debugging remotely, you either connect to at already running instance of debugserver, or you ask the lldb-server-platform process to launch one for you.

Thanks, that makes perfect sense!

aprantl accepted this revision.Jul 1 2020, 9:30 AM

From my side this is good to go once everybody else's concerns are addressed.

This revision is now accepted and ready to land.Jul 1 2020, 9:30 AM
davide closed this revision.Sep 3 2020, 12:51 PM

Somebody will pick this up, probably in a different form.