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 (+@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



_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to