[Lldb-commits] [PATCH] D68968: [android/process info] Introduce bundle id

[Pavel Labath via Phabricator via lldb-commits]

labath added a reviewer: jingham.
labath added subscribers: danalbert, jingham.
labath added a comment.

Introducing a "bundle" identifier as a first class concept sounds reasonable to me, particularly if that concept can be applied to more than one platform. But since we're talking about iOS, it would be good to have the apple folks sign off on this idea too (+ at jingham).

Independently, I am wondering if there's a better way to link the process id to a bundle. Using argv[0] might be ok if we're using it just for display purposes, but if we're going to be doing other stuff based on that identifier, it would be better to get it from a more reliable source. Unfortunately, I was not able to find a more "reasonable source", but maybe @danalbert has an idea.

In D68968#1709706 <https://reviews.llvm.org/D68968#1709706>, @clayborg wrote:

> I would like to see the m_executable always contain the path to "app_process" binary. Arg0 is currently used when spawning via posix_spawn or fork/exec to control the name of the binary that is actually passed on the command line. For example you might specify "clang++" as your binary. If we resolved this to a binary we would find it resolves to "clang++@ -> clang", but we want to pass in clang++ as the arg0 so the compiler knows to  run in C++ mode. So I would like Arg0 to be the actual argument that the client would like to be passed to the executable. Then m_bundle_id can be used by the platform launching code to launch the app. Also, by having m_executable set to "app_process", we can create a valid target in LLDB using the ProcessInfo and then launch/attach.


FWIW, even in the previous implementation the idea was the "executable" field would point to the real exe (or be empty, if we can't locate it). And the argv array would still contain the best approximation of the arguments process was invoked with -- only an approximation, because on linux it's possible (and relatively common) for a process to overwrite it's argv[0] to alter the "ps" output. This is what we were trying to emulate by having `GetName` return argv[0] if the executable path was unknown.



================
Comment at: lldb/source/Host/linux/Host.cpp:220-222
+  if (process_info.GetNameAsStringRef().empty() &&
+      !process_info.GetArg0().empty()) {
+    process_info.SetBundleID(process_info.GetArg0());
----------------
How sure are we that the app processes are the only ones which have the exe link unreadable? Will that be true on all phones or just the recent ones with all the selinux stuff?

I was hoping that there is some more reliable way of fetching this information, but there doesn't seem to be anything except [[ https://developer.android.com/reference/android/app/ActivityManager.RunningAppProcessInfo.html | ActivityManager.RunningAppProcessInfo ]], which I don't know if it can be accessed from lldb, either host- or device-side.

@danalbert, any ideas here?


================
Comment at: lldb/source/Utility/ProcessInfo.cpp:45-46
 const char *ProcessInfo::GetName() const {
+  if (m_executable.GetFilename().IsEmpty() && !m_bundle_id.empty())
+    return m_bundle_id.c_str();
   return m_executable.GetFilename().GetCString();
----------------
What should be the order of preference here? It seems like it would be more natural to use "bundle id" as the "name" even if the executable path happens to be available/readable.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68968/new/

https://reviews.llvm.org/D68968