[android/process info] Introduce display_name

[wallace]

Summary

On systems like android, there are cases in which a process name can correspond to a package name (e.g. com.test.app), which is not an executable path, but instead a bundle id. In other cases, the names can correspond to special system processes whose executable path is not available (e.g. [intr_syncd]) or even kernel threads (e.g. [kworker/6:3]). So far ProcessInfo has been assuming that the process name is an executable path and for cases without executable path, no process name has been shown when invoking platform process list.
Now I'm adding a display_name field whose sole purpose is be the name to be shown when dumping ProcessInfo in cases like platform process list.
In the specific case of android, the bundle id is Arg0 when /proc/<pid>/exe is unreadable, so we can use it as display_name. For caess like system processes or kernel threads, the name is in /proc/<pid>/stat.

After this change, apk packages, system processes, and kernel threads appear in the process list

PID PARENT USER TRIPLE NAME

1 0 root /init
2 0 root [kthreadd]
3 2 root [ksoftirqd/0]
5 2 root [kworker/0:0H]
...
26176 2 root [irq/145-arm-smm]
26177 2 root [irq/146-arm-smm]
26308 2 root [kworker/2:5]
26598 926 u0_a111 com.samsung.android.app.cocktailbarservice:edgelighting
26758 926 u0_a102 com.samsung.android.messaging
26959 926 u0_a116 com.asurion.android.verizon.vms:DefendServiceVzSecure
30407 926 u0_a13 android.process.acore
31011 926 u0_a54 android.process.media
32209 926 u0_a223 com.facebook.katana

[clayborg]

I think it would be nice to have a new member to ProcessInfo like:

std::string m_bundle_id;

This notion works for MacOS and for Android. When launching on iOS, we need to application bundle identifier to do the launching as the install of the app registers the app with the OS app launcher and is launched using its bundle identifier.

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.

[wallace]

now using bundle_id

[wallace]

nit

[wallace]

.

[clayborg]

LGTM. Pavel?

[labath]

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, @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.

lldb/source/Host/linux/Host.cpp

254–256

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 ActivityManager.RunningAppProcessInfo, which I don't know if it can be accessed from lldb, either host- or device-side.

@danalbert, any ideas here?

lldb/source/Utility/ProcessInfo.cpp

45–46

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.

[wallace]

lldb/source/Host/linux/Host.cpp

254–256

Another option I've just discovered is to invoke pm list packages to get the list of all apks and if an Arg0 is in that list, then it's a package.
That seems good enough

[jingham]

As Greg said, iOS (and macOS as well, though less directly) have the notion of bundleID. At present, lldb doesn't directly use/figure out the bundle ID, though it could either from the binary itself or from debugserver, which does have to know that. As far as I know we always also have the path, the bundle ID is inferred from the App package the binary path points to. So that complication should not be present on iOS.

Anyway, I don't see any problem with fetching and displaying the bundleID.

I don't think it would be good to make it hard to see the actual path (if you have it) as well as the bundle ID. If you are working on system components, you want to know that you are running some hand-built copy of a binary and not the pre-installed one. So we want to make it easy to see "which thing with this bundleID am I actually running". Other than that this seems fine to me.

[labath]

In D68968#1712018, @jingham wrote:

I don't think it would be good to make it hard to see the actual path (if you have it) as well as the bundle ID. If you are working on system components, you want to know that you are running some hand-built copy of a binary and not the pre-installed one. So we want to make it easy to see "which thing with this bundleID am I actually running". Other than that this seems fine to me.

Thanks, Jim. This part is interesting. On android the application "path" is mostly uninteresting, because it will always be "/system/bin/app_proces" (as the "app" is really just a shared library loaded into that process), and AFAIK it is not even possible to run an application (an least on an unrooted phone) from a different location.

What would you say is the right way to display this in the "platform process list" output? Would it be ok if in non-verbose mode we displayed only one of these things (bundle id, path base name, argv[0], probably in that order), and then for the non-verbose mode listed each thing separately?

lldb/source/Host/linux/Host.cpp

254–256

That should prevent us accidentally setting an incorrect bundle id, but it does not prevent a process from deliberately changing its argv[0] to the name of some other installed package. That seems suboptimal, particularly if we're later going to use start using the bundle id for other than just display purposes (e.g. for issuing "am kill" commands). So, I am still wondering if we shouldn't go back to using argv[0] for the purpose of "process list", and leave the "bundle id" field for cases where we can get this information from a more reliable source (e.g. reading it from the apk, or fetching it from the android package manager, etc). What do you think?

[danalbert]

In D68968#1710520, @labath wrote:

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.

@enh might

lldb/source/Host/linux/Host.cpp

254–256

@enh

[wallace]

Thanks for your feedback and to @clayborg for an offline discussion we had.

I'm going to add three new attributes to the ProcessInfo class, with corresponding parameters in the gdb-remote packet

• display_name: This is a custom display name that the server can set for a given process. This will supersede any other other attribute in the GetProcessName call. There are interesting cases that are worth mentioning for Android:
  • Kernel threads and system processes are displayed like [kworker/u:0] [khubd] by ps on Android. At least on modern devices ps.c identify those processes as the ones with unreadable /proc/<pid>/cmdline and unreadable /proc/<pid>/exe. The name is gotten from /proc/<pid>/stat. There's some generic information about this here https://unix.stackexchange.com/questions/22121/what-do-the-brackets-around-processes-mean. In this case both the actual executable and args are not known, so it's better to leave those fields empty and store the display name in this new field.
  • Custom apk process names: apks can launch processes and subprocesses with custom names. The custom name has the form com.example.app:custom_name. It's always that way and it's documented here https://developer.android.com/guide/topics/manifest/application-element#proc (go to the android:process section). A given apk can have several subprocesses, each one with a different custom name, e.g. com.samsung.services:Core, com.samsung.services:Monitor, etc. In this case, the package name is known and a display_name field would be useful to store the entire custom name.

• bundle_id: This will be exactly the apk package name or the iOS bundle name inferred by the server. I plan to make a best effort guess for modern android devices, leaving old devices as cases to implement as needed. I plan to use pm list packages for this, given that this is the only reliable way to get all the apk names. Besides, I'll check /proc<pid>/stat for the process name and not arg0. It seems that /stat is not modifiable the same way arg0 is.

• bundle_path: On android this is the path the apk path. This will also be useful for iOS, because app bundles are also stored somewhere. Fortunately, the command pm list packages -f, shows the list of apks along with their corresponding paths on disk. This command doesn't work on old devices, but still, I wouldn't prioritize them now.

For the platform process list command, I'll make the GetProcessName function look for the actual name from these sources in the given order: display_name -> bundle_id -> exe path
In the case of the --verbose mode, I'll show all bundle information and display name fields

[labath]

Thank you for doing the investigation, and the detailed summary. I'm going to respond inline.

In D68968#1713788, @wallace wrote:

Thanks for your feedback and to @clayborg for an offline discussion we had.

I'm going to add three new attributes to the ProcessInfo class, with corresponding parameters in the gdb-remote packet

• display_name: This is a custom display name that the server can set for a given process. This will supersede any other other attribute in the GetProcessName call. There are interesting cases that are worth mentioning for Android:
  • Kernel threads and system processes are displayed like [kworker/u:0] [khubd] by ps on Android. At least on modern devices ps.c identify those processes as the ones with unreadable /proc/<pid>/cmdline and unreadable /proc/<pid>/exe. The name is gotten from /proc/<pid>/stat. There's some generic information about this here https://unix.stackexchange.com/questions/22121/what-do-the-brackets-around-processes-mean. In this case both the actual executable and args are not known, so it's better to leave those fields empty and store the display name in this new field.
  • Custom apk process names: apks can launch processes and subprocesses with custom names. The custom name has the form com.example.app:custom_name. It's always that way and it's documented here https://developer.android.com/guide/topics/manifest/application-element#proc (go to the android:process section). A given apk can have several subprocesses, each one with a different custom name, e.g. com.samsung.services:Core, com.samsung.services:Monitor, etc. In this case, the package name is known and a display_name field would be useful to store the entire custom name.

I think this is an excellent idea. It makes it clear that this is a separate concept, and that one should not rely on this being identical to any other concept (exe path, bundle it, etc.)

• bundle_id: This will be exactly the apk package name or the iOS bundle name inferred by the server. I plan to make a best effort guess for modern android devices, leaving old devices as cases to implement as needed. I plan to use pm list packages for this, given that this is the only reliable way to get all the apk names. Besides, I'll check /proc<pid>/stat for the process name and not arg0. It seems that /stat is not modifiable the same way arg0 is.

Having a bundle_id field in this struct seems fine. I'm much less enthusiastic about lldb-server "inferring" its contents. In fact, after reading the android docs you linked above, I'm starting to become opposed to the idea. I'll copy the interesting bits of that document:

android:process
    The name of a process where all components of the application should run. Each component can override this default by setting its own process attribute.

    By default, Android creates a process for an application when the first of its components needs to run.

The way I read this is that this gives an application a fully documented way of changing it's process name to _anything_ it wants, including the name of another package (or at least, something that looks very similar to it). The app doesn't even have to go native to scribble into some random bytes in memory (which could be considered unsupported). I also think that going for /proc/<pid>/stat is a downgrade, as the name there comes from /proc/<pid>/comm, which is a file that can be written to by anyone with appropriate permissions (as opposed to argv[0], which requires permissions to write to the memory of that process -- a harder thing to come by). It is also limited to 16 characters, so it likely will not contain the full package name.

What's the end goal here? My impression was that you're trying to to make "platform process list" output useful on android, but it seems to me like this is already achieved by having the "display name" field. Can we postpone this part until we actually need it? I'm hoping that at that point it will become clearer whether these hac^H^Heuristics are really needed, or if there's another way to achieve the same goal. For instance when running doing a "process attach PID", we can (reliably) get the user id that PID runs under, and then use "pm list" to tie that user id to a package name that can be given to the "run-as" command -- no need to guess something in the implementation of GetProcessInfo.

• bundle_path: On android this is the path the apk path. This will also be useful for iOS, because app bundles are also stored somewhere. Fortunately, the command pm list packages -f, shows the list of apks along with their corresponding paths on disk. This command doesn't work on old devices, but still, I wouldn't prioritize them now.

Likewise, the bundle_path concept seems fine, but I have doubts about the methods used to retrieve it, particularly as having two different apps share the same process is a legitimate and recommended way of reducing the memory footprint ("By setting this attribute to a process name that's shared with another application, you can arrange for components of both applications to run in the same process").

[wallace]

man, thanks for your feedback!
Indeed, i was trying to solve some problems that don't exist yet. Later when I add apk debugging support, I'll figure out what's the best way to retrieve apk specific information, but for now display_name is more than enough

[clayborg]

sounds like we have a plan!

[labath]

Cool. I'm glad we could figure this out.

[wallace]

now using display_name instead of bundle_id. I've also changed the diff title and description

[labath]

This looks pretty good. I just have one quick question about the /comm file.

lldb/source/Host/linux/Host.cpp

205–222

This should return the same value as /proc/<pid>/comm, except that you don't need to do any fancy parsing. Are there any cases where we cannot just read the /comm file ?

[wallace]

lldb/source/Host/linux/Host.cpp

205–222

you are right! I'll just use it directly

[wallace]

now reading from comm

lldb/docs/lldb-gdb-remote.txt

 //  platform. The first call gets the first match and subsequent calls
 //  to qsProcessInfo gets the subsequent matches. Return an error EXX,
 //  where XX are two hex digits, when no more matches are available.
 //
 // PRIORITY TO IMPLEMENT
 //  Required. The qfProcessInfo packet can be followed by a ':' and
 //  some key value pairs. The key value pairs in the command are:
 //
-//  KEY           VALUE     DESCRIPTION
-//  ===========   ========  ================================================
-//  "name"        ascii-hex An ASCII hex string that contains the name of
-//                          the process that will be matched.
-//  "name_match"  enum      One of: "equals", "starts_with", "ends_with",
-//                          "contains" or "regex"
-//  "pid"         integer   A string value containing the decimal process ID
-//  "parent_pid"  integer   A string value containing the decimal parent
-//                          process ID
-//  "uid"         integer   A string value containing the decimal user ID
-//  "gid"         integer   A string value containing the decimal group ID
-//  "euid"        integer   A string value containing the decimal effective user ID
-//  "egid"        integer   A string value containing the decimal effective group ID
-//  "all_users"   bool      A boolean value that specifies if processes should
-//                          be listed for all users, not just the user that the
-//                          platform is running as
-//  "triple"      string    An ASCII triple string ("x86_64",
-//                          "x86_64-apple-macosx", "armv7-apple-ios")
-//  "args"        string    A string value containing the process arguments
-//                          separated by the character '-', where each argument is
-//                          hex-encoded. It includes argv[0].
+//  KEY             VALUE      DESCRIPTION
+//  ==============  =========  ================================================
+//  "name"          ascii-hex  An ASCII hex string that contains the name of
+//                             the process that will be matched.
+//  "name_match"    enum       One of: "equals", "starts_with", "ends_with",
+//                             "contains" or "regex"
+//  "pid"           integer    A string value containing the decimal process ID
+//  "parent_pid"    integer    A string value containing the decimal parent
+//                             process ID
+//  "uid"           integer    A string value containing the decimal user ID
+//  "gid"           integer    A string value containing the decimal group ID
+//  "euid"          integer    A string value containing the decimal effective
+//                             user ID
+//  "egid"          integer    A string value containing the decimal effective
+//                             group ID
+//  "all_users"     bool       A boolean value that specifies if processes
+//                             should be listed for all users, not just the user
+//                             that the platform is running as
+//  "triple"        string     An ASCII triple string ("x86_64",
+//                             "x86_64-apple-macosx", "armv7-apple-ios")
+//  "args"          string     A string value containing the process arguments
+//                             separated by the character '-', where each
+//                             argument is hex-encoded. It includes argv[0].
+//  "display_name"  string     An ASCII optional string for using when
+//                             displaying information about the process. In
+//                             contrast to the "name" field, this value doesn't
+//                             need to correspond to actual system information.
 //
 // The response consists of key/value pairs where the key is separated from the
 // values with colons and each pair is terminated with a semi colon. For a list
 // of the key/value pairs in the response see the "qProcessInfoPID" packet
 // documentation.
 //
 // Sample packet/response:
 // send packet: $qfProcessInfo#00

lldb/include/lldb/Utility/ProcessInfo.h

public:
   lldb::pid_t GetProcessID() const { return m_pid; }
 
   void SetProcessID(lldb::pid_t pid) { m_pid = pid; }
 
   bool ProcessIDIsValid() const { return m_pid != LLDB_INVALID_PROCESS_ID; }
 
   void Dump(Stream &s, Platform *platform) const;
 
+  void SetDisplayName(llvm::StringRef display_name) { m_display_name = display_name; }
+
+  llvm::StringRef GetDisplayName() const { return m_display_name; }
+
   Args &GetArguments() { return m_arguments; }
 
   const Args &GetArguments() const { return m_arguments; }
 
   llvm::StringRef GetArg0() const;
 
   void SetArg0(llvm::StringRef arg);
 
   void SetArguments(const Args &args, bool first_arg_is_executable);
 
   void SetArguments(char const **argv, bool first_arg_is_executable);
 
   Environment &GetEnvironment() { return m_environment; }
   const Environment &GetEnvironment() const { return m_environment; }
 
 protected:
   FileSpec m_executable;
+  std::string m_display_name; // There are special programs like Android apks or
+  // kernel threads, whose executable path might not reflect accurately the name
+  // they should expose to the user and it might even be impossible to get the
+  // executable path. This field can be useful for these cases.
   std::string m_arg0; // argv[0] if supported. If empty, then use m_executable.
   // Not all process plug-ins support specifying an argv[0] that differs from
   // the resolved platform executable (which is in m_executable)
   Args m_arguments; // All program arguments except argv[0]
   Environment m_environment;
   uint32_t m_uid;
   uint32_t m_gid;
   ArchSpec m_arch;

lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestPlatformClient.py

 import lldb
 import binascii
 import os
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test.decorators import *
 from gdbclientutils import *
 
+
 def hexlify(string):
     return binascii.hexlify(string.encode()).decode()
 
+
 class TestPlatformClient(GDBRemoteTestBase):
 
     def test_process_list_with_all_users(self):
         """Test connecting to a remote linux platform"""
 
         class MyResponder(MockGDBServerResponder):
             def __init__(self):
                 MockGDBServerResponder.__init__(self)
-                self.currentQsProc = 0
+                self.currentProc = 0
                 self.all_users = False
 
-            def qfProcessInfo(self, packet):
-                if "all_users:1" in packet:
-                    self.all_users = True
-                    name = hexlify("/a/test_process")
-                    args = "-".join(map(hexlify,
-                                        ["/system/bin/sh", "-c", "/data/local/tmp/lldb-server"]))
-                    return "pid:10;ppid:1;uid:2;gid:3;euid:4;egid:5;name:" + name + ";args:" + args + ";"
-                else:
-                    self.all_users = False
-                    return "E04"
+            def _processInfo0(self):
 
-            def qsProcessInfo(self):
-                if self.all_users:
-                    if self.currentQsProc == 0:
-                        self.currentQsProc = 1
-                        name = hexlify("/b/another_test_process")
-                        # This intentionally has a badly encoded argument
-                        args = "X".join(map(hexlify,
-                                            ["/system/bin/ls", "--help"]))
-                        return "pid:11;ppid:2;uid:3;gid:4;euid:5;egid:6;name:" + name + ";args:" + args + ";"
-                    elif self.currentQsProc == 1:
-                        self.currentQsProc = 0
+            def _processInfo1(self):
+
+            def _processInfo2(self):
+                # a process without args but with a display_name, which can happen on android
+                display_name = hexlify("com.test.app:Core")
+                return "pid:12;ppid:3;uid:4;gid:5;euid:6;egid:7;name:;args:;display_name:" + display_name + ";"
+
+            def qfProcessInfo(self, packet):
+                self.all_users = "all_users:1" in packet
+                self.currentProc = 1
+                return self._processInfo0()
+
+            def qsProcessInfo(self):
+                if self.all_users:
+                    if self.currentProc == 1:
+                        self.currentProc = 2
+                        return self._processInfo1()
+                    elif self.currentProc == 2:
+                        self.currentProc = 3
+                        return self._processInfo2()
+                    else:
+                        self.currentProc = 0
                         return "E04"
                 else:
                     return "E04"
 
         self.server.responder = MyResponder()
 
         try:
             self.runCmd("platform select remote-linux")
             self.runCmd("platform connect connect://localhost:%d" %
                         self.server.port)
             self.assertTrue(self.dbg.GetSelectedPlatform().IsConnected())
             self.expect("platform process list -x",
-                        substrs=["2 matching processes were found", "test_process", "another_test_process"])
+                        substrs=["3 matching processes were found", "test_process", "another_test_process", "com.test.app:Core"])
             self.expect("platform process list -xv",
                         substrs=[
                             "PID    PARENT USER       GROUP      EFF USER   EFF GROUP  TRIPLE                         ARGUMENTS",
                             "10     1      2          3          4          5                                         /system/bin/sh -c /data/local/tmp/lldb-server",
                             "11     2      3          4          5          6"])
-            self.expect("platform process list -xv", substrs=["/system/bin/ls"], matching=False)
+            self.expect("platform process list -xv",
+                        substrs=["/system/bin/ls", "com.test.app:Core"], matching=False)
             self.expect("platform process list",
-                        error=True,
-                        substrs=["error: no processes were found on the \"remote-linux\" platform"])
+                        substrs=["1 matching process was found"])
         finally:
             self.dbg.GetSelectedPlatform().DisconnectRemote()

lldb/source/Host/linux/Host.cpp

static void GetProcessEnviron(::pid_t pid, ProcessInstanceInfo &process_info) {
   llvm::StringRef Rest = Environ->getBuffer();
   while (!Rest.empty()) {
     llvm::StringRef Var;
     std::tie(Var, Rest) = Rest.split('\0');
     process_info.GetEnvironment().insert(Var);
   }
 }
 
+static bool GetProcessNameFromComm(::pid_t pid, std::string& name) {
+  auto BufferOrError = getProcFile(pid, "comm");
+  if (!BufferOrError)
+    return false;
+
+  std::unique_ptr<llvm::MemoryBuffer> Stat = std::move(*BufferOrError);
+  llvm::StringRef Content = Stat->getBuffer();
+  if (Content.empty())
+    return false;
+
+  // comm might end with new line
+  name = Content.trim();
+  return true;
+}
+
+static void SetProcessDisplayName(::pid_t pid, ProcessInstanceInfo& process_info) {
+  if (!process_info.GetNameAsStringRef().empty())
+    return;
+  if (!process_info.GetArg0().empty()) {
+      // When /proc/<pid>/exe is not readable, then we use arg0 as display name.
+      // On Android devices this might contain the apk package name.
+      process_info.SetDisplayName(process_info.GetArg0());
+      return;
+  }
+  // If /proc/<pid>/cmdline is not readable, then it might correspond to a kernel thread
+  // or system process. We fallback to reading from /proc<pid>/stat for a display name.
+  std::string name;
+  if (GetProcessNameFromComm(pid, name)) {
+    // We follow the guideline of surrounding the name with brackets, as explained here
+    // https://unix.stackexchange.com/questions/22121/what-do-the-brackets-around-processes-mean
+    process_info.SetDisplayName("[" + name + "]");
+  }
+}
+
 static bool GetProcessAndStatInfo(::pid_t pid,
                                   ProcessInstanceInfo &process_info,
                                   ProcessState &State, ::pid_t &tracerpid) {
   tracerpid = 0;
   process_info.Clear();
 
   process_info.SetProcessID(pid);
 
   GetExePathAndArch(pid, process_info);
   GetProcessArgs(pid, process_info);
   GetProcessEnviron(pid, process_info);
+  // Get fallback display name
+  SetProcessDisplayName(pid, process_info);
 
   // Get User and Group IDs and get tracer pid.
   if (!GetStatusInfo(pid, process_info, State, tracerpid))
     return false;
 
   return true;
 }
 
 uint32_t Host::FindProcesses(const ProcessInstanceInfoMatch &match_info,
                              ProcessInstanceInfoList &process_infos) {
   static const char procdir[] = "/proc/";
 
   DIR *dirproc = opendir(procdir);

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp

while (response.GetNameColonValue(name, value)) {
             break;
           }
           if (is_arg0)
             process_info.SetArg0(arg);
           else
             process_info.GetArguments().AppendArgument(arg);
           is_arg0 = false;
         }
+      } else if (name.equals("display_name")) {
+        StringExtractor extractor(value);
+        std::string display_name;
+        extractor.GetHexByteString(display_name);
+        process_info.SetDisplayName(display_name);
       } else if (name.equals("cputype")) {
         value.getAsInteger(0, cpu);
       } else if (name.equals("cpusubtype")) {
         value.getAsInteger(0, sub);
       } else if (name.equals("vendor")) {
         vendor = value;
       } else if (name.equals("ostype")) {
         os_type = value;

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp

void GDBRemoteCommunicationServerCommon::CreateProcessInfoResponse(
   response.Printf(
       "pid:%" PRIu64 ";ppid:%" PRIu64 ";uid:%i;gid:%i;euid:%i;egid:%i;",
       proc_info.GetProcessID(), proc_info.GetParentProcessID(),
       proc_info.GetUserID(), proc_info.GetGroupID(),
       proc_info.GetEffectiveUserID(), proc_info.GetEffectiveGroupID());
   response.PutCString("name:");
   response.PutStringAsRawHex8(proc_info.GetExecutableFile().GetCString());
 
-  response.PutChar(';');
-  response.PutCString("args:");
+  response.PutCString(";args:");
   response.PutStringAsRawHex8(proc_info.GetArg0());
   for (auto &arg : proc_info.GetArguments()) {
     response.PutChar('-');
     response.PutStringAsRawHex8(arg.ref());
   }
 
+  response.PutCString(";display_name:");
+  response.PutStringAsRawHex8(proc_info.GetDisplayName());
+
   response.PutChar(';');
   const ArchSpec &proc_arch = proc_info.GetArchitecture();
   if (proc_arch.IsValid()) {
     const llvm::Triple &proc_triple = proc_arch.GetTriple();
     response.PutCString("triple:");
     response.PutStringAsRawHex8(proc_triple.getTriple());
     response.PutChar(';');
   }

lldb/source/Utility/ProcessInfo.cpp

void ProcessInfo::Clear() {
   m_arguments.Clear();
   m_environment.clear();
   m_uid = UINT32_MAX;
   m_gid = UINT32_MAX;
   m_arch.Clear();
   m_pid = LLDB_INVALID_PROCESS_ID;
 }
 
+// On systems like android, there are cases in which a process name can
+// correspond to a bundle id (e.g. com.test.app), which is not an executable
+// path.
 const char *ProcessInfo::GetName() const {
+  if (!m_display_name.empty())
+    return m_display_name.c_str();
   return m_executable.GetFilename().GetCString();
 }
 
 llvm::StringRef ProcessInfo::GetNameAsStringRef() const {
+  if (!m_display_name.empty())
+    return m_display_name;
   return m_executable.GetFilename().GetStringRef();
 }
 
 void ProcessInfo::Dump(Stream &s, Platform *platform) const {
   s << "Executable: " << GetName() << "\n";
   s << "Triple: ";
   m_arch.DumpTriple(s);
   s << "\n";