[android/process list] support showing process arguments

[wallace]

Summary

The qfProcessInfo and qsProcessInfo packets currently don't set the processes' arguments, however the platform process list -v command tries to print it.
In this diff I'm adding the arguments as part of the packet, and now the command shows the arguments just like on mac.

On Mac:

507    1      wallace    1876110778 wallace    1876110778 x86_64-apple-macosx      /usr/libexec/secd
503    1      wallace    1876110778 wallace    1876110778 x86_64-apple-macosx      /usr/libexec/secinitd
501    1      wallace    1876110778 wallace    1876110778 x86_64-apple-macosx      /usr/libexec/languageassetd --firstLogin
497    1      wallace    1876110778 wallace    1876110778 x86_64-apple-macosx      /usr/libexec/trustd --agent
496    1      wallace    1876110778 wallace    1876110778 x86_64-apple-macosx      /usr/libexec/lsd
494    1      wallace    1876110778 wallace    1876110778 x86_64-apple-macosx      /System/Library/Frameworks/CoreTelephony.framework/Support/CommCenter -L
491    1      wallace    1876110778 wallace    1876110778 x86_64-apple-macosx      /usr/sbin/distnoted agent
489    1      wallace    1876110778 wallace    1876110778 x86_64-apple-macosx      /usr/libexec/UserEventAgent (Aqua)
484    1      wallace    1876110778 wallace    1876110778 x86_64-apple-macosx      /usr/sbin/cfprefsd agent
483    1      wallace    1876110778 wallace    1876110778 x86_64-apple-macosx      /System/Library/Frameworks/LocalAuthentication.framework/Support/coreauthd

On android:

1561   1016   root       0                     0          aarch64-unknown-linux-android  /system/bin/ip6tables-restore--noflush -w -v
1805   982    1000       1000                  1000                                      android:drmService
1811   982    10189      10189                 10189                                     com.qualcomm.embms:remote
1999   1      1000       1000                  1000       aarch64-unknown-linux-android  /system/bin/tlc_serverCCM
2332   982    10038      10038                 10038                                     com.android.systemui
2378   983    1053       1053                  1053                                      webview_zygote
2448   982    5013       5013                  5013                                      com.sec.location.nsflp2
2465   982    10027      10027                 10027                                     com.google.android.gms.persistent

[labath]

Including the args sounds like a good idea, but I don't think the chosen encoding scheme is very good. The encoding done in GetCommandString is very naive and not reversible. Since you're hex-encoding the result anyway, and the nul character cannot be present inside an argument you could use it to delimit the individual arguments (i.e. 666f6f00626172 -> {"foo", "bar"}). Or, you could look at how the $A packet transmits arguments, and implement something similar.

Also, you should write a test for this. I think it should be possible to run a process with known arguments, and then verify that they show up in "platform process list" output. Alternatively, the client part of the protocol can also be tested via c++ unit tests (see unittests/Process/gdb-remote). The advantage of that approach is that you're able to inject invalid packets and test the handling of those. In an ideal world, we'd have both kinds of these tests, but we're pretty far from that, so I'd settle for at least one of them. :)

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

615–616

When you're running clang format, please make sure it only formats the lines that you have modified. I've you're using the standard git-clang-format integration, this should be as simple as git clang-format HEAD^. Please revert these unrelated changes.

1961–1965

I don't fully understand the what this does. Is it trying to set the executable name as argv[0]? Wouldn't it be better to send the argv[0] separately (together with the rest of the args array), just in case the process has a special argv[0].

[wallace]

• Encoding differently the arguments. Now it shouldn't have any corner cases
• I'm also sending from the server all the args, including arg0
• In the client, when displaying the process name, I'm using arg0 as fallback if the exe path is empty
• Fixed formatting

I still need to finish testing

[wallace]

added a basic python test

It was a nice learning experience and fortunately there was no need to add any intrusive code

[wallace]

damn, i overwrote this patch lol

[wallace]

added a test

[labath]

The encoding scheme looks fine to me. There's just two more additional things that came to mind:

• r373789 by @jasonmolenda reminded me that we have a document for describing the gdb-remote protocol extensions. It would be good to add sentence or two about the encoding of the process arguments there.
• It's great that you've added gdb-client test for this. Among other things, it enables us to inject "faulty" packets and test the handling of those (such as the GetHexByteString failure I mention in the inline comment). However, this only tests the client-side of the feature. Given that the arguments of a process (unlike the UID it runs as for instance) is something that we can reasonably control from a test, I think we should have an end-to-end test too. I think it would be easiest to test this with python. You can probably use one of the "attach" tests as a starting point, only instead of attaching to the process, you'd run "platform process list" and verify the process (and it's arguments) show up in the output.

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

51

?

lldb/source/Host/linux/Host.cpp

159–160 ↗

(On Diff #223376)

This doesn't seem right... What about processes invoked with empty arguments? (my_prog "" "")

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

1932

We usually don't use STL iostreams in llvm. And it definitely doesn't look like they are needed here. Why do something like the while(!empty) split('-') pattern in GetProcessArgs above?

1934

I think it would be simpler if you just parsed this in a regular loop, did something like if(!process_info.GetArguments().empty()) process_info.SetArg0(...) after the loop

1939

What happens if this fails?

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

1194

s/.c_str()/.ref(). Generally, always try to use the non-c string apis when they are available...

lldb/source/Utility/ProcessInfo.cpp

42

Can you put this bit into a separate patch? I'd like to get more opinions on whether this is the right place to do this, and I don't want to blur that discussion with the mechanics of passing command line arguments through the gdb-remote protocol.

[aprantl]

This test fails on green dragon:

http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/2538/changes#detail0
http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/2538/testReport/junit/lldb-api/functionalities_gdb_remote_client/TestPlatformClient_py/

lldb-api.functionalities/gdb_remote_client.TestPlatformClient.py (from lldb-api)

Failing for the past 1 build (Since Failed#2538 )
Took 0.66 sec.
add description
Stacktrace

lldb version 10.0.99 (http://labmaster3.local/git/llvm-project.git revision 1edb7e0b6f390b066f5218208a7c8ac974ee243c)
  clang revision 089a334c39d06e958607e1e8e0c9796f9387f512
  llvm revision 089a334c39d06e958607e1e8e0c9796f9387f512
LLDB library dir: /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/bin
LLDB import library dir: /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/bin
libstdcxx tests will not be run because: Don't know how to build with libstdcxx on macosx
Skipping following debug info categories: ['dwo']

Session logs for test failures/errors/unexpected successes will go into directory '/Users/buildslave/jenkins/workspace/lldb-cmake/test/logs'
Command invoked: /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/test/API/dotest.py --arch=x86_64 -s /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lldb-test-traces -S nm -u CXXFLAGS -u CFLAGS --executable /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./bin/lldb --dsymutil /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./bin/dsymutil --filecheck /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./bin/FileCheck -C /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./bin/clang --codesign-identity lldb_codesign --server /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./bin/debugserver --arch x86_64 --build-dir /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lldb-test-build.noindex -s=/Users/buildslave/jenkins/workspace/lldb-cmake/test/logs -t --env TERM=vt100 --env LLVM_LIBS_DIR=/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./lib --build-dir /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/tools/lldb/lldb-test-build.noindex --lldb-module-cache-dir /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/tools/lldb/lldb-test-build.noindex/module-cache-lldb/lldb-api --clang-module-cache-dir /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/tools/lldb/lldb-test-build.noindex/module-cache-clang/lldb-api /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client -p TestPlatformClient.py
Change dir to: /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client
runCmd: settings set symbols.enable-external-lookup false
output: 

runCmd: settings set plugin.process.gdb-remote.packet-timeout 60
output: 

runCmd: settings set symbols.clang-modules-cache-path "/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/tools/lldb/lldb-test-build.noindex/module-cache-lldb/lldb-api"
output: 

runCmd: settings set use-color false
output: 

runCmd: platform select remote-linux
output:   Platform: remote-linux
 Connected: no


runCmd: platform connect connect://localhost:52264
output:   Platform: remote-linux
  Hostname: (null)
 Connected: yes
WorkingDir: /


runCmd: platform process list -x
runCmd failed!
error: no processes were found on the "remote-linux" platform


FAIL: LLDB (/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/bin/clang-10-x86_64) :: test_process_list_with_all_users (TestPlatformClient.TestPlatformClient)
Restore dir to: /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/tools/lldb/test
======================================================================
FAIL: test_process_list_with_all_users (TestPlatformClient.TestPlatformClient)
   Test connecting to a remote linux platform
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestPlatformClient.py", line 30, in test_process_list_with_all_users
    substrs=["1 matching process was found", "test_process"])
  File "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2309, in expect
    inHistory=inHistory)
  File "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2068, in runCmd
    msg if (msg) else CMD_MSG(cmd))
AssertionError: False is not True : Command 'platform process list -x
Error output:
error: no processes were found on the "remote-linux" platform
' returns successfully
Config=x86_64-/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/bin/clang-10
----------------------------------------------------------------------
Ran 1 test in 0.040s

RESULT: FAILED (0 passes, 1 failures, 0 errors, 0 skipped, 0 expected failures, 0 unexpected successes)

Can you please take a look?

If you're not available I'll revert the patch later today to get the bots green again.

[wallace]

i'm reverting it, thanks!

[aprantl]

The re-committed variant still doesn't work :-)

[wallace]

address comments

Btw, @labath, could you point me to a example of a full end to end test like the attach one you mention?
I haven't been able to find it :(

[labath]

In D68293#1708863, @wallace wrote:

address comments

Btw, @labath, could you point me to a example of a full end to end test like the attach one you mention?
I haven't been able to find it :(

I think you can use TestProcessAttach.py as a starting point. If you look at the test_attach_to_process_by_id function, all it does is launch a process, and then immediately attaches to it.

So, what could your test do, is also call self.spawnSubprocess, but also pass it some arguments. Then, instead of attaching, you'd run "platform process list" and verify that the process (and its arguments) are there.

[wallace]

Add end to end test

[labath]

lldb/docs/lldb-gdb-remote.txt

1456

Does that include argv[0]? I take it does, but argv[0] is funny, so it's better to be explicit about that.

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

63–66

Is this a negative check? We usually use expect(..., error=True) for that

[wallace]

lldb/docs/lldb-gdb-remote.txt

1456

Ohh, I've just read this in ProcessInfo.h

// 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

I think I have to make some adjustments

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

63–66

It's a negative test, but error=True checks for the success of the command itself, it doesn't check the substrs.
I took at look at the base classes for testing and it seems I could add something like not_contain_substrs, but the code seems very fragile

[labath]

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

63–66

Ok, how about matching=False then? Or maybe you could just put the entirety of the output to expect into the patterns argument, as it should not contain any values which vary from run to run.

[wallace]

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

63–66

damn, i was looking at the wrong implementation of def expect...

[wallace]

Addressed comments. It turns out from the definition of ProcessInfo that Arguments shuoldn't contain arg0, so I updated the code accordingly.
I ran the test suite locally and I didn't see any failure caused due to that, so it should be okay.

[labath]

Looks pretty good, just two quick comments.

lldb/packages/Python/lldbsuite/test/commands/platform/process/TestProcessList.py

16–18

You don't need this. This was present in the other test because it was (also) attaching by name, but when attaching by pid, you can do with the default "a.out".

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

1941

Why a single space? I can understand an empty string, but a " " seems very arbitrary...

[wallace]

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

1941

that's indeed a typo...

[wallace]

addressed comments

[stella.stamenova]

This is causing a failure on the Windows Bot:

http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/9920

lldb/docs/lldb-gdb-remote.txt

 LLDB has added new GDB server packets to better support multi-threaded and
 remote debugging. Why? Normally you need to start the correct GDB and the
 correct GDB server when debugging. If you have mismatch, then things go wrong
-very quickly. LLDB makes extensive use of the GDB remote protocol and we 
+very quickly. LLDB makes extensive use of the GDB remote protocol and we
 wanted to make sure that the experience was a bit more dynamic where we can
 discover information about a remote target with having to know anything up
-front. We also ran into performance issues with the existing GDB remote 
+front. We also ran into performance issues with the existing GDB remote
 protocol that can be overcome when using a reliable communications layer.
 Some packets improve performance, others allow for remote process launching
 (if you have an OS), and others allow us to dynamically figure out what
 registers a thread might have. Again with GDB, both sides pre-agree on how the
-registers will look (how many, their register number,name and offsets). We 
+registers will look (how many, their register number,name and offsets). We
 prefer to be able to dynamically determine what kind of architecture, OS and
 vendor we are debugging, as well as how things are laid out when it comes to
 the thread register contexts. Below are the details on the new packets we have
 added above and beyond the standard GDB remote protocol packets.
 
 //----------------------------------------------------------------------
 // "QStartNoAckMode"
 //

 //----------------------------------------------------------------------
 // "QEnvironment:NAME=VALUE"
 //
 // BRIEF
 //  Setup the environment up for a new child process that will soon be
 //  launched using the "A" packet.
 //
 // NB: key/value pairs are sent as-is so gdb-remote protocol meta characters
-//     (e.g. '#' or '$') are not acceptable.  If any non-printable or 
+//     (e.g. '#' or '$') are not acceptable.  If any non-printable or
 //     metacharacters are present in the strings, QEnvironmentHexEncoded
 //     should be used instead if it is available.  If you don't want to
-//     scan the environment strings before sending, prefer 
+//     scan the environment strings before sending, prefer
 //     the QEnvironmentHexEncoded packet over QEnvironment, if it is
 //     available.
 //
 // PRIORITY TO IMPLEMENT
 //  Low. Only needed if the remote target wants to launch a target after
 //  making a connection to a GDB server that isn't already connected to
 //  an inferior process.
 //----------------------------------------------------------------------

 //  EXX;AAAAAAAAA
 //
 //  where AAAAAAAAA will be a hex encoded ASCII string.
 //  XX is hex encoded byte number.
 //
 //  It must be noted that even if the client has enabled reporting
 //  strings in error replies, it must not expect error strings to all
 //  error replies.
-// 
+//
 // PRIORITY TO IMPLEMENT
 //  Low. Only needed if the remote target wants to provide strings that
 //  are human readable along with an error code.
 //----------------------------------------------------------------------
 
 send packet: $QEnableErrorStrings
 read packet: $OK#00
 
 //----------------------------------------------------------------------
 // "QSetSTDIN:<ascii-hex-path>"
 // "QSetSTDOUT:<ascii-hex-path>"
 // "QSetSTDERR:<ascii-hex-path>"
 //
 // BRIEF
-//  Setup where STDIN, STDOUT, and STDERR go prior to sending an "A" 
+//  Setup where STDIN, STDOUT, and STDERR go prior to sending an "A"
 //  packet.
 //
 // PRIORITY TO IMPLEMENT
 //  Low. Only needed if the remote target wants to launch a target after
 //  making a connection to a GDB server that isn't already connected to
 //  an inferior process.
 //----------------------------------------------------------------------
 

 
 This packet must be sent  _prior_ to sending a "A" packet.
 
 //----------------------------------------------------------------------
 // QListThreadsInStopReply
 //
 // BRIEF
 //  Enable the threads: and thread-pcs: data in the question-mark packet
-//  ("T packet") responses when the stub reports that a program has 
+//  ("T packet") responses when the stub reports that a program has
 //  stopped executing.
 //
 // PRIORITY TO IMPLEMENT
 //  Performance.  This is a performance benefit to lldb if the thread id's
 //  and thread pc values are provided to lldb in the T stop packet -- if
 //  they are not provided to lldb, lldb will likely need to send one to
 //  two packets per thread to fetch the data at every private stop.
 //----------------------------------------------------------------------

 //  Discover register information from the remote GDB server.
 //
 // PRIORITY TO IMPLEMENT
 //  High. Any target that can self describe its registers, should do so.
 //  This means if new registers are ever added to a remote target, they
 //  will get picked up automatically, and allows registers to change
 //  depending on the actual CPU type that is used.
 //
-//  NB: As of summer 2015, lldb can get register information from the 
+//  NB: As of summer 2015, lldb can get register information from the
 //  "qXfer:features:read:target.xml" FSF gdb standard register packet
 //  where the stub provides register definitions in an XML file.
 //  If qXfer:features:read:target.xml is supported, qRegisterInfo does
 //  not need to be implemented.
 //----------------------------------------------------------------------
 
 With LLDB, for register information, remote GDB servers can add
 support for the "qRegisterInfoN" packet where "N" is a zero based

 read packet: $name:err;bitsize:32;offset:700;encoding:uint;format:hex;set:Exception State Registers;#00
 send packet: $qRegisterInfo39#00
 read packet: $name:faultvaddr;bitsize:64;offset:704;encoding:uint;format:hex;set:Exception State Registers;#00
 send packet: $qRegisterInfo3a#00
 read packet: $E45#00
 
 As we see above we keep making subsequent calls to the remote server to
 discover all registers by increasing the number appended to qRegisterInfo and
-we get a response back that is a series of "key=value;" strings. 
+we get a response back that is a series of "key=value;" strings.
 
 The offset: fields should not leave a gap anywhere in the g/G packet -- the
 register values should be appended one after another.  For instance, if the
-register context for a thread looks like 
+register context for a thread looks like
 
 struct rctx {
     uint32_t gpr1;  // offset 0
     uint32_t gpr2;  // offset 4
     uint32_t gpr3;  // offset 8
     uint64_t fp1;   // offset 16
 };
 
 You may end up with a 4-byte gap between gpr3 and fp1 on architectures
 that align values like this.  The correct offset: value for fp1 is 12 -
-in the g/G packet fp1 will immediately follow gpr3, even though the 
-in-memory thread structure has an empty 4 bytes for alignment between 
+in the g/G packet fp1 will immediately follow gpr3, even though the
+in-memory thread structure has an empty 4 bytes for alignment between
 these two registers.
 
 The keys and values are detailed below:
 
 Key         Value
 ==========  ================================================================
 name        The primary register name as a string ("rbp" for example)
 
 alt-name    An alternate name for a register as a string ("fp" for example for
             the above "rbp")
 
 bitsize     Size in bits of a register (32, 64, etc).  Base 10.
 
 offset      The offset within the "g" and "G" packet of the register data for
             this register.  This is the byte offset once the data has been
-            transformed into binary, not the character offset into the g/G 
+            transformed into binary, not the character offset into the g/G
             packet.  Base 10.
 
-encoding    The encoding type of the register which must be one of: 
+encoding    The encoding type of the register which must be one of:
 
                  uint (unsigned integer)
                  sint (signed integer)
                  ieee754 (IEEE 754 float)
                  vector (vector register)
 
 format      The preferred format for display of this register. The value must
             be one of:
 
                 binary
                 decimal
                 hex
                 float
                 vector-sint8
-                vector-uint8 
+                vector-uint8
                 vector-sint16
                 vector-uint16
                 vector-sint32
                 vector-uint32
                 vector-float32
                 vector-uint128
 
 set         The register set name as a string that this register belongs to.
 
 gcc         The GCC compiler registers number for this register (used for
             EH frame and other compiler information that is encoded in the
             executable files). The supplied number will be decoded like a
             string passed to strtoul() with a base of zero, so the number
             can be decimal, or hex if it is prefixed with "0x".
 
-            NOTE: If the compiler doesn't have a register number for this 
+            NOTE: If the compiler doesn't have a register number for this
             register, this key/value pair should be omitted.
 
 dwarf       The DWARF register number for this register that is used for this
             register in the debug information. The supplied number will be decoded
             like a string passed to strtoul() with a base of zero, so the number
             can be decimal, or hex if it is prefixed with "0x".
 
-            NOTE: If the compiler doesn't have a register number for this 
+            NOTE: If the compiler doesn't have a register number for this
             register, this key/value pair should be omitted.
 
 generic     If the register is a generic register that most CPUs have, classify
             it correctly so the debugger knows. Valid values are one of:
-             pc  (a program counter register. for example "name=eip;" (i386), 
-                  "name=rip;" (x86_64), "name=r15;" (32 bit arm) would 
+             pc  (a program counter register. for example "name=eip;" (i386),
+                  "name=rip;" (x86_64), "name=r15;" (32 bit arm) would
                   include a "generic=pc;" key value pair)
-             sp  (a stack pointer register. for example "name=esp;" (i386), 
-                  "name=rsp;" (x86_64), "name=r13;" (32 bit arm) would 
+             sp  (a stack pointer register. for example "name=esp;" (i386),
+                  "name=rsp;" (x86_64), "name=r13;" (32 bit arm) would
                   include a "generic=sp;" key value pair)
-             fp  (a frame pointer register. for example "name=ebp;" (i386), 
-                   "name=rbp;" (x86_64), "name=r7;" (32 bit arm with macosx 
+             fp  (a frame pointer register. for example "name=ebp;" (i386),
+                   "name=rbp;" (x86_64), "name=r7;" (32 bit arm with macosx
                    ABI) would include a "generic=fp;" key value pair)
-             ra  (a return address register. for example "name=lr;" (32 bit ARM) 
+             ra  (a return address register. for example "name=lr;" (32 bit ARM)
                   would include a "generic=ra;" key value pair)
-             fp  (a CPU flags register. for example "name=eflags;" (i386), 
-                  "name=rflags;" (x86_64), "name=cpsr;" (32 bit ARM) 
+             fp  (a CPU flags register. for example "name=eflags;" (i386),
+                  "name=rflags;" (x86_64), "name=cpsr;" (32 bit ARM)
                   would include a "generic=flags;" key value pair)
-             arg1 - arg8 (specified for registers that contain function 
+             arg1 - arg8 (specified for registers that contain function
                       arguments when the argument fits into a register)
 
 container-regs
-            The value for this key is a comma separated list of raw hex (optional 
+            The value for this key is a comma separated list of raw hex (optional
             leading "0x") register numbers.
 
             This specifies that this register is contained in other concrete
             register values. For example "eax" is in the lower 32 bits of the
             "rax" register value for x86_64, so "eax" could specify that it is
             contained in "rax" by specifying the register number for "rax" (whose
             register number is 0x00)
-            
             "container-regs:00;"
-            
             If a register is comprised of one or more registers, like "d0" is ARM
             which is a 64 bit register, it might be made up of "s0" and "s1". If
             the register number for "s0" is 0x20, and the register number of "s1"
             is "0x21", the "container-regs" key/value pair would be:
-            
             "container-regs:20,21;"
-            
             This is handy for defining what GDB used to call "pseudo" registers.
             These registers are never requested by LLDB via the register read
             or write packets, the container registers will be requested on behalf
             of this register.
-            
 invalidate-regs
-            The value for this key is a comma separated list of raw hex (optional 
+            The value for this key is a comma separated list of raw hex (optional
             leading "0x") register numbers.
-            
             This specifies which register values should be invalidated when this
             register is modified. For example if modifying "eax" would cause "rax",
             "eax", "ax", "ah", and "al" to be modified where rax is 0x0, eax is 0x15,
             ax is 0x25, ah is 0x35, and al is 0x39, the "invalidate-regs" key/value
             pair would be:
 
             "invalidate-regs:0,15,25,35,39;"
-            
             If there is a single register that gets invalidated, then omit the comma
             and just list a single register:
-            
             "invalidate-regs:0;"
-            
             This is handy when modifying a specific register can cause other
             register values to change. For example, when debugging an ARM target,
             modifying the CPSR register can cause the r8 - r14 and cpsr value to
-            change depending on if the mode has changed. 
+            change depending on if the mode has changed.
 
 //----------------------------------------------------------------------
 // "qPlatform_shell"
 //
 // BRIEF
 //  Run a command in a shell on the connected remote machine.
 //
 // PRIORITY TO IMPLEMENT

 osmajor: optional, specifies the major version number of the OS (e.g. for macOS 10.12.2, it would be 10)
 osminor: optional, specifies the minor version number of the OS (e.g. for macOS 10.12.2, it would be 12)
 ospatch: optional, specifies the patch level number of the OS (e.g. for macOS 10.12.2, it would be 2)
 
 //----------------------------------------------------------------------
 // "qGDBServerVersion"
 //
 // BRIEF
-//  Get version information about this implementation of the gdb-remote 
+//  Get version information about this implementation of the gdb-remote
 //  protocol.
 //
 // PRIORITY TO IMPLEMENT
 //  High. This packet is usually very easy to implement and can help
-//  LLDB to work around bugs in a server's implementation when they 
+//  LLDB to work around bugs in a server's implementation when they
 //  are found.
 //----------------------------------------------------------------------
 
 The goal of this packet is to provide enough information about an
 implementation of the gdb-remote-protocol server that lldb can
 work around implementation problems that are discovered after the
 version has been released/deployed.  The name and version number
 should be sufficiently unique that lldb can unambiguously identify
 the origin of the program (for instance, debugserver from lldb) and
 the version/submission number/patch level of the program - whatever
 is appropriate for your server implementation.
 
 The packet follows the key-value pair model, semicolon separated.
 
 send packet: $qGDBServerVersion#00
 read packet: $name:debugserver;version:310.2;#00
 
 Other clients may find other key-value pairs to be useful for identifying
-a gdb stub.  Patch level, release name, build number may all be keys that 
-better describe your implementation's version.  
+a gdb stub.  Patch level, release name, build number may all be keys that
+better describe your implementation's version.
 Suggested key names:
 
   name   : the name of your remote server - "debugserver" is the lldb standard
            implementation
 
   version : identifies the version number of this server
 
   patch_level : the patch level of this server

 //----------------------------------------------------------------------
 // "qProcessInfo"
 //
 // BRIEF
 //  Get information about the process we are currently debugging.
 //
 // PRIORITY TO IMPLEMENT
 //  Medium.  On systems which can launch multiple different architecture processes,
-//  the qHostInfo may not disambiguate sufficiently to know what kind of 
+//  the qHostInfo may not disambiguate sufficiently to know what kind of
 //  process is being debugged.
 //  e.g. on a 64-bit x86 Mac system both 32-bit and 64-bit user processes are possible,
-//  and with Mach-O universal files, the executable file may contain both 32- and 
+//  and with Mach-O universal files, the executable file may contain both 32- and
 //  64-bit slices so it may be impossible to know until you're attached to a real
 //  process to know what you're working with.
 //
 //  All numeric fields return base-16 numbers without any "0x" prefix.
 //----------------------------------------------------------------------
 
 An i386 process:
 

 endian: is one of "little", "big", or "pdp"
 ptrsize: is a number that represents how big pointers are in bytes
 
 
 //----------------------------------------------------------------------
 // "qShlibInfoAddr"
 //
 // BRIEF
-//  Get an address where the dynamic linker stores information about 
+//  Get an address where the dynamic linker stores information about
 //  where shared libraries are loaded.
 //
 // PRIORITY TO IMPLEMENT
 //  High if you have a dynamic loader plug-in in LLDB for your target
 //  triple (see the "qHostInfo" packet) that can use this information.
-//  Many times address load randomization can make it hard to detect 
+//  Many times address load randomization can make it hard to detect
 //  where the dynamic loader binary and data structures are located and
 //  some platforms know, or can find out where this information is.
 //
-//  Low if you have a debug target where all object and symbol files 
+//  Low if you have a debug target where all object and symbol files
 //  contain static load addresses.
 //----------------------------------------------------------------------
 
 LLDB and GDB both support the "qShlibInfoAddr" packet which is a hint to each
 debugger as to where to find the dynamic loader information. For darwin
 binaries that run in user land this is the address of the "all_image_infos"
 structure in the "/usr/lib/dyld" executable, or the result of a TASK_DYLD_INFO
 call. The result is returned as big endian hex bytes that are the address

 // BRIEF
 //  Get information about why a thread, whose ID is "<tid>", is stopped.
 //
 // PRIORITY TO IMPLEMENT
 //  High if you need to support multi-threaded or multi-core debugging.
 //  Many times one thread will hit a breakpoint and while the debugger
 //  is in the process of suspending the other threads, other threads
 //  will also hit a breakpoint. This packet allows LLDB to know why all
-//  threads (live system debug) / cores (JTAG) in your program have 
-//  stopped and allows LLDB to display and control your program 
+//  threads (live system debug) / cores (JTAG) in your program have
+//  stopped and allows LLDB to display and control your program
 //  correctly.
 //----------------------------------------------------------------------
-    
 LLDB tries to use the "qThreadStopInfo" packet which is formatted as
 "qThreadStopInfo%x" where %x is the hex thread ID. This requests information
 about why a thread is stopped. The response is the same as the stop reply
 packets and tells us what happened to the other threads. The standard GDB
 remote packets love to think that there is only _one_ reason that _one_ thread
 stops at a time. This allows us to see why all threads stopped and allows us
 to implement better multi-threaded debugging support.
 

 
 The allocate memory packet starts with "_M<size>,<permissions>". It returns a
 raw big endian address value, or "" for unimplemented, or "EXX" for an error
 code. The packet is formatted as:
 
 char packet[256];
 int packet_len;
 packet_len = ::snprintf (
-    packet, 
-    sizeof(packet), 
-    "_M%zx,%s%s%s", 
+    packet,
+    sizeof(packet),
+    "_M%zx,%s%s%s",
     (size_t)size,
     permissions & lldb::ePermissionsReadable ? "r" : "",
     permissions & lldb::ePermissionsWritable ? "w" : "",
     permissions & lldb::ePermissionsExecutable ? "x" : "");
 
 You request a size and give the permissions. This packet does NOT need to be
 implemented if you don't want to support running JITed code. The return value
 is just the address of the newly allocated memory as raw big endian hex bytes.

 //  frame. Otherwise we must assume we are in some JIT'ed code (not JIT
 //  code that LLDB has made) and assume that no registers are available
 //  in higher stack frames.
 //----------------------------------------------------------------------
 
 We added a way to get information for a memory region. The packet is:
 
     qMemoryRegionInfo:<addr>
-    
 Where <addr> is a big endian hex address. The response is returned in a series
 of tuples like the data returned in a stop reply packet. The currently valid
 tuples to return are:
 
-    start:<start-addr>; // <start-addr> is a big endian hex address that is 
+    start:<start-addr>; // <start-addr> is a big endian hex address that is
                         // the start address of the range that contains <addr>
-    
     size:<size>;    // <size> is a big endian hex byte size of the address
                     // of the range that contains <addr>
-    
     permissions:<permissions>;  // <permissions> is a string that contains one
                                 // or more of the characters from "rwx"
 
     name:<name>; // <name> is a hex encoded string that contains the name of
                  // the memory region mapped at the given address. In case of
                  // regions backed by a file it have to be the absolute path of
                  // the file while for anonymous regions it have to be the name
                  // associated to the region if that is available.
-                                
     error:<ascii-byte-error-string>; // where <ascii-byte-error-string> is
-                                     // a hex encoded string value that 
+                                     // a hex encoded string value that
                                      // contains an error string
-                                    
 If the address requested is not in a mapped region (e.g. we've jumped through
-a NULL pointer and are at 0x0) currently lldb expects to get back the size 
+a NULL pointer and are at 0x0) currently lldb expects to get back the size
 of the unmapped region -- that is, the distance to the next valid region.
 For instance, with a macOS process which has nothing mapped in the first
 4GB of its address space, if we're asking about address 0x2,
 
   qMemoryRegionInfo:2
   start:2;size:fffffffe;
 
 The lack of 'permissions:' indicates that none of read/write/execute are valid

 // will all be escaped with '}' (0x7d) character and then XOR'ed with 0x20.
 //
 // A typical use to read 512 bytes at 0x1000 would look like
 //
 // x0x1000,0x200
 //
 // The "0x" prefixes are optional - like most of the gdb-remote packets,
 // omitting them will work fine; these numbers are always base 16.
-// 
-// The length of the payload is not provided.  A reliable, 8-bit clean, 
+//
+// The length of the payload is not provided.  A reliable, 8-bit clean,
 // transport layer is assumed.
 //----------------------------------------------------------------------
 
 //----------------------------------------------------------------------
 // Detach and stay stopped:
 //
 // We extended the "D" packet to specify that the monitor should keep the
 // target suspended on detach.  The normal behavior is to resume execution
 // on detach.  We will send:
 //
 //  qSupportsDetachAndStayStopped:
 //
 // to query whether the monitor supports the extended detach, and if it does,
 // when we want the monitor to detach but not resume the target, we will
 // send:
-// 
+//
 //   D1
 //
 // In any case, if we want the normal detach behavior we will just send:
 //
 //   D
 //----------------------------------------------------------------------
 
 //----------------------------------------------------------------------
 // QSaveRegisterState
 // QSaveRegisterState;thread:XXXX;
 //
 // BRIEF
 //  The QSaveRegisterState packet tells the remote debugserver to save
-//  all registers and return a non-zero unique integer ID that 
+//  all registers and return a non-zero unique integer ID that
 //  represents these save registers. If thread suffixes are enabled the
-//  second form of this packet is used, otherwise the first form is 
+//  second form of this packet is used, otherwise the first form is
 //  used. This packet is called prior to executing an expression, so
-//  the remote GDB server should do anything it needs to in order to 
+//  the remote GDB server should do anything it needs to in order to
 //  ensure the registers that are saved are correct. On macOS this
-//  involves calling "thread_abort_safely(mach_port_t thread)" to 
+//  involves calling "thread_abort_safely(mach_port_t thread)" to
 //  ensure we get the correct registers for a thread in case it is
 //  currently having code run on its behalf in the kernel.
 //
 // RESPONSE
 //  unsigned - The save_id result is a non-zero unsigned integer value
 //             that can be passed back to the GDB server using a
 //             QRestoreRegisterState packet to restore the registers
 //             one time.
 //  "EXX" - or an error code in the form of EXX where XX is a
 //  hex error code.
 //
 // PRIORITY TO IMPLEMENT
 //  Low, this is mostly a convenience packet to avoid having to send all
 //  registers via a g packet. It should only be implemented if support
 //  for the QRestoreRegisterState is added.
 //----------------------------------------------------------------------
 
 //----------------------------------------------------------------------
 // QRestoreRegisterState:<save_id>
 // QRestoreRegisterState:<save_id>;thread:XXXX;
 //
 // BRIEF
-//  The QRestoreRegisterState packet tells the remote debugserver to 
+//  The QRestoreRegisterState packet tells the remote debugserver to
 //  restore all registers using the "save_id" which is an unsigned
-//  integer that was returned from a previous call to 
+//  integer that was returned from a previous call to
 //  QSaveRegisterState. The restoration process can only be done once
-//  as the data backing the register state will be freed upon the 
+//  as the data backing the register state will be freed upon the
 //  completion of the QRestoreRegisterState command.
 //
-//  If thread suffixes are enabled the second form of this packet is 
+//  If thread suffixes are enabled the second form of this packet is
 //  used, otherwise the first form is used.
 //
 // RESPONSE
 //  "OK" - if all registers were successfully restored
 //  "EXX" - for any errors
 //
 // PRIORITY TO IMPLEMENT
 //  Low, this is mostly a convenience packet to avoid having to send all

 //  information about your threads.
 //
 // DESCRIPTION
 //  Standard GDB remote stop reply packets are reply packets sent in
 //  response to a packet  that made the program run. They come in the
 //  following forms:
 //
 //  "SAA"
-//  "S" means signal and "AA" is a hex signal number that describes why 
+//  "S" means signal and "AA" is a hex signal number that describes why
 //  the thread or stopped. It doesn't specify which thread, so the "T"
 //  packet is recommended to use instead of the "S" packet.
 //
 //  "TAAkey1:value1;key2:value2;..."
-//  "T" means a thread stopped due to a unix signal where "AA" is a hex 
-//  signal number that describes why the program stopped. This is 
+//  "T" means a thread stopped due to a unix signal where "AA" is a hex
+//  signal number that describes why the program stopped. This is
 //  followed by a series of key/value pairs:
 //      - If key is a hex number, it is a register number and value is
 //        the hex value of the register in debuggee endian byte order.
 //      - If key == "thread", then the value is the big endian hex
 //        thread-id of the stopped thread.
 //      - If key == "core", then value is a hex number of the core on
 //        which the stop was detected.
 //      - If key == "watch" or key == "rwatch" or key == "awatch", then

 // LLDB EXTENSIONS
 //
 //  We have extended the "T" packet to be able to also understand the
 //  following keys and values:
 //
 //  KEY           VALUE     DESCRIPTION
 //  ===========   ========  ================================================
 //  "metype"      unsigned  mach exception type (the value of the EXC_XXX enumerations)
-//                          as an unsigned integer. For targets with mach 
+//                          as an unsigned integer. For targets with mach
 //                          kernels only.
 //
 //  "mecount"     unsigned  mach exception data count as an unsigned integer
 //                          For targets with mach kernels only.
 //
 //  "medata"      unsigned  There should be "mecount" of these and it is the data
-//                          that goes along with a mach exception (as an unsigned 
+//                          that goes along with a mach exception (as an unsigned
 //                          integer). For targets with mach kernels only.
 //
 //  "name"        string    The name of the thread as a plain string. The string
 //                          must not contain an special packet characters or
 //                          contain a ':' or a ';'. Use "hexname" if the thread
 //                          name has special characters.
 //
 //  "hexname"     ascii-hex An ASCII hex string that contains the name of the thread
 //
 //  "qaddr"       hex       Big endian hex value that contains the libdispatch
 //                          queue address for the queue of the thread.
 //
 //  "reason"      enum      The enumeration must be one of:
 //                          "trace" the program stopped after a single instruction
 //                              was executed on a core. Usually done when single
 //                              stepping past a breakpoint
 //                          "breakpoint" a breakpoint set using a 'z' packet was hit.
 //                          "trap" stopped due to user interruption
 //                          "signal" stopped due to an actual unix signal, not
 //                              just the debugger using a unix signal to keep
 //                              the GDB remote client happy.
-//                          "watchpoint". Should be used in conjunction with 
+//                          "watchpoint". Should be used in conjunction with
 //                              the "watch"/"rwatch"/"awatch" key value pairs.
 //                          "exception" an exception stop reason. Use with
 //                              the "description" key/value pair to describe the
 //                              exceptional event the user should see as the stop
 //                              reason.
 //  "description" ascii-hex An ASCII hex string that contains a more descriptive
 //                          reason that the thread stopped. This is only needed
 //                          if none of the key/value pairs are enough to
 //                          describe why something stopped.
 //
 //  "threads"     comma-sep-base16  A list of thread ids for all threads (including
 //                                  the thread that we're reporting as stopped) that
 //                                  are live in the process right now.  lldb may
 //                                  request that this be included in the T packet via
 //                                  the QListThreadsInStopReply packet earlier in
 //                                  the debug session.
-//                                  
+//
 //                                  Example:
 //                                  threads:63387,633b2,63424,63462,63486;
 //
 //  "thread-pcs"  comma-sep-base16  A list of pc values for all threads that currently
 //                                  exist in the process, including the thread that
 //                                  this T packet is reporting as stopped.
 //                                  This key-value pair will only be emitted when the
 //                                  "threads" key is already included in the T packet.
 //                                  The pc values correspond to the threads reported
 //                                  in the "threads" list.  The number of pcs in the
-//                                  "thread-pcs" list will be the same as the number of 
+//                                  "thread-pcs" list will be the same as the number of
 //                                  threads in the "threads" list.
-//                                  lldb may request that this be included in the T 
-//                                  packet via the QListThreadsInStopReply packet 
+//                                  lldb may request that this be included in the T
+//                                  packet via the QListThreadsInStopReply packet
 //                                  earlier in the debug session.
-//                                  
+//
 //                                  Example:
 //                                  thread-pcs:dec14,2cf872b0,2cf8681c,2d02d68c,2cf716a8;
 //
 // BEST PRACTICES:
 //  Since register values can be supplied with this packet, it is often useful
 //  to return the PC, SP, FP, LR (if any), and FLAGS registers so that separate
 //  packets don't need to be sent to read each of these registers from each
 //  thread.
 //
 //  If a thread is stopped for no reason (like just because another thread
-//  stopped, or because when one core stops all cores should stop), use a 
-//  "T" packet with "00" as the signal number and fill in as many key values 
+//  stopped, or because when one core stops all cores should stop), use a
+//  "T" packet with "00" as the signal number and fill in as many key values
 //  and registers as possible.
 //
-//  LLDB likes to know why a thread stopped since many thread control 
+//  LLDB likes to know why a thread stopped since many thread control
 //  operations like stepping over a source line, actually are implemented
 //  by running the process multiple times. If a breakpoint is hit while
 //  trying to step over a source line and LLDB finds out that a breakpoint
 //  is hit in the "reason", we will know to stop trying to do the step
 //  over because something happened that should stop us from trying to
 //  do the step. If we are at a breakpoint and we disable the breakpoint
 //  at the current PC and do an instruction single step, knowing that
 //  we stopped due to a "trace" helps us know that we can continue
-//  running versus stopping due to a "breakpoint" (if we have two 
+//  running versus stopping due to a "breakpoint" (if we have two
 //  breakpoint instruction on consecutive instructions). So the more info
 //  we can get about the reason a thread stops, the better job LLDB can
-//  do when controlling your process. A typical GDB server behavior is 
+//  do when controlling your process. A typical GDB server behavior is
 //  to send a SIGTRAP for breakpoints _and_ also when instruction single
-//  stepping, in this case the debugger doesn't really know why we 
+//  stepping, in this case the debugger doesn't really know why we
 //  stopped and it can make it hard for the debugger to control your
 //  program correctly. What if a real SIGTRAP was delivered to a thread
 //  while we were trying to single step? We wouldn't know the difference
 //  with a standard GDB remote server and we could do the wrong thing.
 //
 // PRIORITY TO IMPLEMENT
 //  High. Having the extra information in your stop reply packets makes
 //  your debug session more reliable and informative.
 //----------------------------------------------------------------------
- 
 
 //----------------------------------------------------------------------
 // PLATFORM EXTENSION - for use as a GDB remote platform
 //----------------------------------------------------------------------
 // "qfProcessInfo"
 // "qsProcessInfo"
 //
 // BRIEF
 //  Get the first process info (qfProcessInfo) or subsequent process
-//  info (qsProcessInfo) for one or more processes on the remote 
+//  info (qsProcessInfo) for one or more processes on the remote
 //  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 
+//  "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", 
+//  "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 
+//  "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 
+//                          be listed for all users, not just the user that the
 //                          platform is running as
-//  "triple"      string    An ASCII triple string ("x86_64", 
+//  "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].
 //
 // 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

 //----------------------------------------------------------------------
 // "qProcessInfoPID:PID"
 //
 // BRIEF
 //  Have the remote platform get detailed information on a process by
 //  ID. PID is specified as a decimal integer.
 //
 // PRIORITY TO IMPLEMENT
-//  Optional. 
+//  Optional.
 //
 // 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.
 //
 // The key value pairs in the response are:
 //
 //  KEY           VALUE     DESCRIPTION
 //  ===========   ========  ================================================

 // read packet: $pid:60050;ppid:59948;uid:7746;gid:11;euid:7746;egid:11;name:6c6c6462;triple:x86_64-apple-macosx;#00
 //----------------------------------------------------------------------
 
 //----------------------------------------------------------------------
 // "vAttachName"
 //
 // BRIEF
 //  Same as vAttach, except instead of a "pid" you send a process name.
-//  
+//
 // PRIORITY TO IMPLEMENT
 //  Low. Only needed for "process attach -n".  If the packet isn't supported
 //  then "process attach -n" will fail gracefully.  So you need only to support
 //  it if attaching to a process by name makes sense for your environment.
 //----------------------------------------------------------------------
 
 //----------------------------------------------------------------------
 // "vAttachWait"

 //  by name if it exists, and if it does not, it will wait for a process
 //  of that name to appear and attach to it.
 //
 // PRIORITY TO IMPLEMENT
 //  Low. Only needed to implement "process attach -w -i false -n".  If
 //  you don't implement it but do implement -n AND lldb can somehow get
 //  a process list from your device, it will fall back on scanning the
 //  process list, and sending vAttach or vAttachWait depending on
-//  whether the requested process exists already.  This is racy, 
+//  whether the requested process exists already.  This is racy,
 //  however, so if you want to support this behavior it is better to
 //  support this packet.
 //----------------------------------------------------------------------
 
 //----------------------------------------------------------------------
 // "jThreadExtendedInfo"
 //
 // BRIEF
 //  This packet, which takes its arguments as JSON and sends its reply as
-//  JSON, allows the gdb remote stub to provide additional information 
+//  JSON, allows the gdb remote stub to provide additional information
 //  about a given thread.
 //
 // PRIORITY TO IMPLEMENT
-//  Low.  This packet is only needed if the gdb remote stub wants to 
+//  Low.  This packet is only needed if the gdb remote stub wants to
 //  provide interesting additional information about a thread for the
 //  user.
 //
 // This packet takes its arguments in JSON form ( http://www.json.org ).
 // At a minimum, a thread must be specified, for example:
 //
 //  jThreadExtendedInfo:{"thread":612910}
 //
 // Because this is a JSON string, the thread number is provided in base10.
 // Additional key-value pairs may be provided by lldb to the gdb remote
 // stub.  For instance, on some versions of macOS, lldb can read offset
 // information out of the system libraries.  Using those offsets, debugserver
 // is able to find the Thread Specific Address (TSD) for a thread and include
 // that in the return information.  So lldb will send these additional fields
 // like so:
 //
 //   jThreadExtendedInfo:{"plo_pthread_tsd_base_address_offset":0,"plo_pthread_tsd_base_offset":224,"plo_pthread_tsd_entry_size":8,"thread":612910}
 //
-// There are no requirements for what is included in the response.  A simple 
+// There are no requirements for what is included in the response.  A simple
 // reply on a OS X Yosemite / iOS 8 may include the pthread_t value, the
 // Thread Specific Data (TSD) address, the dispatch_queue_t value if the thread
 // is associated with a GCD queue, and the requested Quality of Service (QoS)
 // information about that thread.  For instance, a reply may look like:
 //
 //  {"tsd_address":4371349728,"requested_qos":{"enum_value":33,"constant_name":"QOS_CLASS_USER_INTERACTIVE","printable_name":"User Interactive"},"pthread_t":4371349504,"dispatch_queue_t":140735087127872}
 //
-// tsd_address, pthread_t, and dispatch_queue_t are all simple key-value pairs.  
-// The JSON standard requires that numbers be expressed in base 10 - so all of 
-// these are.  requested_qos is a dictionary with three key-value pairs in it - 
+// tsd_address, pthread_t, and dispatch_queue_t are all simple key-value pairs.
+// The JSON standard requires that numbers be expressed in base 10 - so all of
+// these are.  requested_qos is a dictionary with three key-value pairs in it -
 // so the UI layer may choose the form most appropriate for displaying to the user.
 //
-// Sending JSON over gdb-remote protocol introduces some problems.  We may be 
+// Sending JSON over gdb-remote protocol introduces some problems.  We may be
 // sending strings with arbitrary contents in them, including the '#', '$', and '*'
 // characters that have special meaning in gdb-remote protocol and cannot occur
 // in the middle of the string.  The standard solution for this would be to require
 // ascii-hex encoding of all strings, or ascii-hex encode the entire JSON payload.
 //
 // Instead, the binary escaping convention is used for JSON data.  This convention
 // (e.g. used for the X packet) says that if '#', '$', '*', or '}' are to occur in
 // the payload, the character '}' (0x7d) is emitted, then the metacharacter is emitted
 // xor'ed by 0x20.  The '}' character occurs in every JSON payload at least once, and
 // '}' ^ 0x20 happens to be ']' so the raw packet characters for a request will look
 // like
 //
 //  jThreadExtendedInfo:{"thread":612910}]
 //
 // on the wire.
 //----------------------------------------------------------------------
 
 //----------------------------------------------------------------------
 // "QEnableCompression"
 //
 // BRIEF
 //  This packet enables compression of the packets that the debug stub sends to lldb.
-//  If the debug stub can support compression, it indictes this in the reply of the 
+//  If the debug stub can support compression, it indictes this in the reply of the
 //  "qSupported" packet.  e.g.
 //   LLDB SENDS:    qSupported:xmlRegisters=i386,arm,mips
 //   STUB REPLIES:  qXfer:features:read+;SupportedCompressions=lzfse,zlib-deflate,lz4,lzma;DefaultCompressionMinSize=384
 //
 //  If lldb knows how to use any of these compression algorithms, it can ask that this
-//  compression mode be enabled.  It may optionally change the minimum packet size 
+//  compression mode be enabled.  It may optionally change the minimum packet size
 //  where compression is used.  Typically small packets do not benefit from compression,
 //  as well as compression headers -- compression is most beneficial with larger packets.
 //
 //  QEnableCompression:type:zlib-deflate;
 //  or
 //  QEnableCompression:type:zlib-deflate;minsize:512;
 //
 //  The debug stub should reply with an uncompressed "OK" packet to indicate that the
 //  request was accepted.  All further packets the stub sends will use this compression.
 //
-//  Packets are compressed as the last step before they are sent from the stub, and 
+//  Packets are compressed as the last step before they are sent from the stub, and
 //  decompressed as the first step after they are received.  The packet format in compressed
 //  mode becomes one of two:
 //
 //   $N<uncompressed payload>#00
 //
 //   $C<size of uncompressed payload in base10>:<compressed payload>#00
 //
 //  Where "#00" is the actual checksum value if noack mode is not enabled.  The checksum
-//  value is for the "N<uncompressed payload>" or 
+//  value is for the "N<uncompressed payload>" or
 //  "C<size of uncompressed payload in base10>:<compressed payload>" bytes in the packet.
 //
 //  The size of the uncompressed payload in base10 is provided because it will simplify
 //  decompression if the final buffer size needed is known ahead of time.
 //
 //  Compression on low-latency connections is unlikely to be an improvement.  Particularly
 //  when the debug stub and lldb are running on the same host.  It should only be used
 //  for slow connections, and likely only for larger packets.
 //
 //  Example compression algorithsm that may be used include
 //
 //    zlib-deflate
 //       The raw DEFLATE format as described in IETF RFC 1951.  With the ZLIB library, you
-//       can compress to this format with an initialization like 
+//       can compress to this format with an initialization like
 //           deflateInit2 (&stream, 5, Z_DEFLATED, -15, 8, Z_DEFAULT_STRATEGY)
 //       and you can decompress with an initialization like
 //           inflateInit2 (&stream, -15)
 //
 //    lz4
 //       https://en.wikipedia.org/wiki/LZ4_(compression_algorithm)
 //       https://github.com/Cyan4973/lz4
 //       The libcompression APIs on darwin systems call this COMPRESSION_LZ4_RAW.

 //
 //  On macOS 10.12, iOS 10, tvOS 10, watchOS 3 and newer, there are two calls.  One requests information
 //  on all shared libraries:
 //       jGetLoadedDynamicLibrariesInfos:{"fetch_all_solibs":true}
 //  And the second requests information about a list of shared libraries, given their load addresses:
 //       jGetLoadedDynamicLibrariesInfos:{"solib_addresses":[8382824135,3258302053,830202858503]}
 //
 //  The second call is both a performance optimization (instead of having lldb read the mach-o header/load commands
-//  out of memory with generic read packets) but also adds additional information in the form of the 
+//  out of memory with generic read packets) but also adds additional information in the form of the
 //  filename of the shared libraries (which is not available in the mach-o header/load commands.)
-//  
+//
 //  An example using the OS X 10.11 style call:
 //
 //  LLDB SENDS: jGetLoadedDynamicLibrariesInfos:{"image_count":1,"image_list_address":140734800075128}
 //  STUB REPLIES: ${"images":[{"load_address":4294967296,"mod_date":0,"pathname":"/tmp/a.out","uuid":"02CF262C-ED6F-3965-9E14-63538B465CFF","mach_header":{"magic":4277009103,"cputype":16777223,"cpusubtype":18446744071562067971,"filetype":2},"segments":{"name":"__PAGEZERO","vmaddr":0,"vmsize":4294967296,"fileoff":0,"filesize":0,"maxprot":0},{"name":"__TEXT","vmaddr":4294967296,"vmsize":4096,"fileoff":0,"filesize":4096,"maxprot":7},{"name":"__LINKEDIT","vmaddr":4294971392,"vmsize":4096,"fileoff":4096,"filesize":152,"maxprot":7}}]}#00
 //
 //  Or pretty-printed,
 //
 //  STUB REPLIES: ${"images":

 // be argued that it should be merged into that packet.  A separate
 // packet was created primarily because lldb needs to specify the
 // number of images to be read and the address from which the initial
 // information is read.  Also the XML DTD would need to be extended
 // quite a bit to provide all the information that the DynamicLoaderMacOSX
 // would need to work correctly on this platform.
 //
 // PRIORITY TO IMPLEMENT
-//  On OS X 10.11, iOS 9, tvOS 9, watchOS 2 and older: Low.  If this packet is absent, 
+//  On OS X 10.11, iOS 9, tvOS 9, watchOS 2 and older: Low.  If this packet is absent,
 //  lldb will read the Mach-O headers/load commands out of memory.
 //  On macOS 10.12, iOS 10, tvOS 10, watchOS 3 and newer: High.  If this packet is absent,
 //  lldb will not know anything about shared libraries in the inferior, or where the main
 //  executable loaded.
 //----------------------------------------------------------------------
 
 //----------------------------------------------------------------------
 // "jThreadsInfo"

lldb/packages/Python/lldbsuite/test/commands/platform/process/Makefile

+CXX_SOURCES := main.cpp
+
+EXE := TestProcess
+
+include Makefile.rules

lldb/packages/Python/lldbsuite/test/commands/platform/process/TestProcessList.py

+"""
+Test process list.
+"""
+
+from __future__ import print_function
+
+
+import os
+import lldb
+import shutil
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class ProcessListTestCase(TestBase):
+
+    mydir = TestBase.compute_mydir(__file__)
+
+    NO_DEBUG_INFO_TESTCASE = True
+
+    def test_process_list_with_args(self):
+        """Test process list show process args"""
+        self.build()
+        exe = self.getBuildArtifact("TestProcess")
+
+        # Spawn a new process
+        popen = self.spawnSubprocess(exe, args=["arg1", "--arg2", "arg3"])
+        self.addTearDownHook(self.cleanupSubprocesses)
+
+        self.expect("platform process list -v",
+                    substrs=["TestProcess arg1 --arg2 arg3", str(popen.pid)])

lldb/packages/Python/lldbsuite/test/commands/platform/process/main.cpp

+#include <stdio.h>
+
+#include <chrono>
+#include <thread>
+
+int main(int argc, char const *argv[]) {
+  std::this_thread::sleep_for(std::chrono::seconds(30));
+  return 0;
+}

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.all_users = False
+
             def qfProcessInfo(self, packet):
                 if "all_users:1" in packet:
-                    return "pid:10;ppid:1;uid:1;gid:1;euid:1;egid:1;name:" + binascii.hexlify("/a/test_process".encode()).decode() + ";"
+                    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"
 
-        self.server.responder = MyResponder()
+            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
+                        return "E04"
+                else:
+                    return "E04"
 
-        self.runCmd("platform select remote-linux")
+        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=["1 matching process was found", "test_process"])
+                        substrs=["2 matching processes were found", "test_process", "another_test_process"])
+            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",
                         error=True,
                         substrs=["error: no processes were found on the \"remote-linux\" platform"])
         finally:
             self.dbg.GetSelectedPlatform().DisconnectRemote()

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

 }
 
 bool GDBRemoteCommunicationClient::GetLoadedDynamicLibrariesInfosSupported() {
   if (m_supports_jLoadedDynamicLibrariesInfos == eLazyBoolCalculate) {
     StringExtractorGDBRemote response;
     m_supports_jLoadedDynamicLibrariesInfos = eLazyBoolNo;
     if (SendPacketAndWaitForResponse("jGetLoadedDynamicLibrariesInfos:",
                                      response,
                                      false) == PacketResult::Success) {
       if (response.IsOKResponse()) {
         m_supports_jLoadedDynamicLibrariesInfos = eLazyBoolYes;
       }
     }
   }
   return m_supports_jLoadedDynamicLibrariesInfos;
 }
 
 bool GDBRemoteCommunicationClient::GetSharedCacheInfoSupported() {
while (response.GetNameColonValue(name, value)) {
         process_info.GetArchitecture().SetTriple(triple.c_str());
       } else if (name.equals("name")) {
         StringExtractor extractor(value);
         // The process name from ASCII hex bytes since we can't control the
         // characters in a process name
         std::string name;
         extractor.GetHexByteString(name);
         process_info.GetExecutableFile().SetFile(name, FileSpec::Style::native);
+      } else if (name.equals("args")) {
+        llvm::StringRef encoded_args(value), hex_arg;
+
+        bool is_arg0 = true;
+        while (!encoded_args.empty()) {
+          std::tie(hex_arg, encoded_args) = encoded_args.split('-');
+          std::string arg;
+          StringExtractor extractor(hex_arg);
+          if (extractor.GetHexByteString(arg) * 2 != hex_arg.size()) {
+            // In case of wrong encoding, we discard all the arguments
+            process_info.GetArguments().Clear();
+            process_info.SetArg0("");
+            break;
+          }
+          if (is_arg0)
+            process_info.SetArg0(arg);
+          else
+            process_info.GetArguments().AppendArgument(arg);
+          is_arg0 = false;
+        }
       } 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;
       }
     }
 
     if (cpu != LLDB_INVALID_CPUTYPE && !vendor.empty() && !os_type.empty()) {
       if (vendor == "apple") {
         process_info.GetArchitecture().SetArchitecture(eArchTypeMachO, cpu,
                                                        sub);
         process_info.GetArchitecture().GetTriple().setVendorName(
             llvm::StringRef(vendor));
         process_info.GetArchitecture().GetTriple().setOSName(
             llvm::StringRef(os_type));
       }
     }
 
     if (process_info.GetProcessID() != LLDB_INVALID_PROCESS_ID)
       return true;

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

void GDBRemoteCommunicationServerCommon::CreateProcessInfoResponse(
     const ProcessInstanceInfo &proc_info, StreamString &response) {
   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.PutStringAsRawHex8(proc_info.GetArg0());
+  for (auto &arg : proc_info.GetArguments()) {
+    response.PutChar('-');
+    response.PutStringAsRawHex8(arg.ref());
+  }
+
   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_environment.clear();
   m_uid = UINT32_MAX;
   m_gid = UINT32_MAX;
   m_arch.Clear();
   m_pid = LLDB_INVALID_PROCESS_ID;
 }
 
 const char *ProcessInfo::GetName() const {
   return m_executable.GetFilename().GetCString();
 }
 
 llvm::StringRef ProcessInfo::GetNameAsStringRef() const {
   return m_executable.GetFilename().GetStringRef();
 }
 
 void ProcessInfo::Dump(Stream &s, Platform *platform) const {
   s << "Executable: " << GetName() << "\n";
if (m_pid != LLDB_INVALID_PROCESS_ID) {
     } else {
       print(&ProcessInstanceInfo::EffectiveUserIDIsValid,
             &ProcessInstanceInfo::GetEffectiveUserID,
             &UserIDResolver::GetUserName);
       s.Printf("%-30s ", arch_strm.GetData());
     }
 
     if (verbose || show_args) {
+      s.PutCString(m_arg0);
       const uint32_t argc = m_arguments.GetArgumentCount();
-      if (argc > 0) {
-        for (uint32_t i = 0; i < argc; i++) {
-          if (i > 0)
-            s.PutChar(' ');
-          s.PutCString(m_arguments.GetArgumentAtIndex(i));
-        }
-      }
     } else {
       s.PutCString(GetName());
     }
 
     s.EOL();
   }
 }