porting lldb for a VLIW architecture

Hi,

I am to port lldb for a VLIW architecture. I am entirely new to lldb. But have some experience in porting gdb for the same architecture.

Somemore insight on my problem of porting lldb for the VLIW architecture. The lldb is to connect the (VLIW architecture) simulator remotely. Both the lldb and the simulator are to run on the linux machine. (the host machine is the linux machine - Ubuntu).

The simulator already has the RSP server support with it (which already worked well with my ‘gdb port for this architecture’). Now I want lldb in place of gdb.

On searching for a starting point on lldb port, I found very few references in the form of few mails at lldb-dev mailing list.

lists.cs.uiuc.edu/pipermail/lldb-dev/2012-January/000770.html

With this I got the below understanding on my lldb porting tasks to that VLIW architecture.

  1. To port lldb for the VLIW architecture, it is must to have the llvm ported to that VLIW architecture. This is because lldb uses few modules of llvm for some functionalities such as expressions evaluation, disassembling.

  2. With llvm ported for the VLIW architecture, in my case following are the lldb modules I have to consider for porting:
    a. Platform plug-in
    b. ABI plug-in
    c. Process plug-in

  3. Platform refers to the host OS on which the lldb runs. In my case I am to run the lldb on linux platform. And since lldb has the support for linux platform, I am not required to do anything on this.

Doubt: Under the Platform plug-in, I see there is a folder “gdb-server”. I don’t understand the significance of this. Should I consider this for my case?

  1. ABI refers to the target architecture description such as the register information, call frame information etc. So I have to create a class for my VLIW architecture (which is a sub-class of lldb_private::ABI).

  2. Process refers to the module that connects lldb to the remote module. lldb has gdb-remote already supported. And hence I am not required to do anything on this.

Can someone help me to go further on this?

Thanks and regards,
Chandra Kumar R.

Hi,

I am to port lldb for a VLIW architecture. I am entirely new to lldb. But have some experience in porting gdb for the same architecture.

Somemore insight on my problem of porting lldb for the VLIW architecture. The lldb is to connect the (VLIW architecture) simulator remotely. Both the lldb and the simulator are to run on the linux machine. (the host machine is the linux machine - Ubuntu).

The simulator already has the RSP server support with it (which already worked well with my 'gdb port for this architecture'). Now I want lldb in place of gdb.

When you say "The simulator already has the RSP server support", does this mean the port implements the GDB remote protocol? Or a custom debug protocol?

On searching for a starting point on lldb port, I found very few references in the form of few mails at lldb-dev mailing list.

lists.cs.uiuc.edu/pipermail/lldb-dev/2012-January/000770.html

With this I got the below understanding on my lldb porting tasks to that VLIW architecture.

1. To port lldb for the VLIW architecture, it is must to have the llvm ported to that VLIW architecture. This is because lldb uses few modules of llvm for some functionalities such as expressions evaluation, disassembling.

Yes.

2. With llvm ported for the VLIW architecture, in my case following are the lldb modules I have to consider for porting:
    a. Platform plug-in
    b. ABI plug-in
    c. Process plug-in

Yes, unless the port to your simulator uses the GDB remote protocol, it which case you can skip step 'c' above. If your simulator does implement the GDB remote protocol, let me know, else, you will need to subclass "lldb_private::Process" into a new process plug-in. This plug-in will also subclass lldb_private::Thread.

3. Platform refers to the host OS on which the lldb runs. In my case I am to run the lldb on linux platform. And since lldb has the support for linux platform, I am not required to do anything on this.

Platform plug-ins do a few things:
- locate paths for files mentioned during a remote debug session.
- locate debug symols for executable files (in case they are separate)
- upload/download files
- install applications (which is an extension of uploading a file as you might have to register the application with the OS)
- list processes
- attach and launch processes
- more

The main thing to note is if you have version 1.2.3 of linux on your local machine and you debug a binary on a 2.3.4 version of linux, you might be asked to locate "/usr/lib/libfoo.so" on your system. If you have a complete copy of the binaries on your local system for the remote 2.3.4 machine, the platform plug-in will be responsible for mapping "/usr/lib/libfoo.so" to "/users/jsmith/src/linux/2.3.4/root/usr/lib/libfoo.so".

The platform also gets to state which architectures it supports so that the platform can be auto selected when given a binary that doesn't match the current host. For example:

% lldb --arch armv6 a.out
Current executable set to 'a.out' (armv6).
(lldb) target list
Current targets:
* target #0: /Volumes/work/gclayton/Documents/devb/attach/a.out ( arch=armv6-apple-ios, platform=remote-ios )

This was run on an x86_64 Mac, but since the binary "a.out" didn't contain "x86_64" or "i386" architectures, LLDB used the currently installed platforms to determine which platform to use. In this case it was "remote-ios". It knew this becauase the "remote-ios" is the only platform that supports the arm architecture currently. The target triple can be further filled out to ensure the propper plug-ins (platform + process + dynamic loader + os plug-in + abi) get selected.

So if you started your LLDB with:

% lldb --arch vliw-<vendor>-<os> a.out

We can select the correct plugins. Is there a vendor and os for the VLIW target? If not, you can always specify "vliw-unknown-unknown" which means, no vendor and no OS, and this can still help the plug-ins to determine which plug-ins will be selected.

Doubt: Under the Platform plug-in, I see there is a folder "gdb-server". I don't understand the significance of this. Should I consider this for my case?

Not unless you want to implement a "lldb-platform" plug-in that runs on the VLIW simulator that implements all of the functionality of the Platform plug-ins.

4. ABI refers to the target architecture description such as the register information, call frame information etc. So I have to create a class for my VLIW architecture (which is a sub-class of lldb_private::ABI).

ABI is for calling convention stuff like when making function calls with simple arguments, where (which register or stack offset) will the arguments be? Also what name mangling is used for the VLIW ABI? If it is the Itanium, you can probably subclass the existing Itanium ABI plug-in for VLIW.

5. Process refers to the module that connects lldb to the remote module. lldb has gdb-remote already supported. And hence I am not required to do anything on this.

Can someone help me to go further on this?

If your simulator supports the GDB remote protocol, you should be ready to try and connect once you get the "vliw" architecture added to LLVM and into LLDB.

Let me know what other questions you have,

Greg Clayton

Thank you. I worked further with your guidance. Kindly see my response
embedded below.

> Hi,
>
> I am to port lldb for a VLIW architecture. I am entirely new to lldb.
> But have some experience in porting gdb for the same architecture.
>
> Somemore insight on my problem of porting lldb for the VLIW
> architecture. The lldb is to connect the (VLIW architecture) simulator
> remotely. Both the lldb and the simulator are to run on the linux machine.
> (the host machine is the linux machine - Ubuntu).
>
> The simulator already has the RSP server support with it (which already
> worked well with my 'gdb port for this architecture'). Now I want lldb in
> place of gdb.

When you say "The simulator already has the RSP server support", does this
mean the port implements the GDB remote protocol? Or a custom debug
protocol?

Yes, simulator implements the GDB remote protocol.

>
> On searching for a starting point on lldb port, I found very few
> references in the form of few mails at lldb-dev mailing list.
>
> lists.cs.uiuc.edu/pipermail/lldb-dev/2012-January/000770.html
>
> With this I got the below understanding on my lldb porting tasks to that
> VLIW architecture.
>
> 1. To port lldb for the VLIW architecture, it is must to have the llvm
> ported to that VLIW architecture. This is because lldb uses few modules of
> llvm for some functionalities such as expressions evaluation, disassembling.

Yes.

> 2. With llvm ported for the VLIW architecture, in my case following are
> the lldb modules I have to consider for porting:
> a. Platform plug-in
> b. ABI plug-in
> c. Process plug-in

Yes, unless the port to your simulator uses the GDB remote protocol, it
which case you can skip step 'c' above. If your simulator does implement the
GDB remote protocol, let me know, else, you will need to subclass
"lldb_private::Process" into a new process plug-in. This plug-in will also
subclass lldb_private::Thread.

My simulator implements the GDB remote protocol. So I can skip step 'c'.

>
> 3. Platform refers to the host OS on which the lldb runs. In my case I
> am to run the lldb on linux platform. And since lldb has the support for
> linux platform, I am not required to do anything on this.

Platform plug-ins do a few things:
- locate paths for files mentioned during a remote debug session.
- locate debug symols for executable files (in case they are separate)
- upload/download files
- install applications (which is an extension of uploading a file as you
might have to register the application with the OS)
- list processes
- attach and launch processes
- more

The main thing to note is if you have version 1.2.3 of linux on your local
machine and you debug a binary on a 2.3.4 version of linux, you might be
asked to locate "/usr/lib/libfoo.so" on your system. If you have a complete
copy of the binaries on your local system for the remote 2.3.4 machine, the
platform plug-in will be responsible for mapping "/usr/lib/libfoo.so" to
"/users/jsmith/src/linux/2.3.4/root/usr/lib/libfoo.so".

The platform also gets to state which architectures it supports so that
the platform can be auto selected when given a binary that doesn't match the
current host. For example:

% lldb --arch armv6 a.out
Current executable set to 'a.out' (armv6).
(lldb) target list
Current targets:
* target #0: /Volumes/work/gclayton/Documents/devb/attach/a.out (
arch=armv6-apple-ios, platform=remote-ios )

This was run on an x86_64 Mac, but since the binary "a.out" didn't contain
"x86_64" or "i386" architectures, LLDB used the currently installed
platforms to determine which platform to use. In this case it was
"remote-ios". It knew this becauase the "remote-ios" is the only platform
that supports the arm architecture currently. The target triple can be
further filled out to ensure the propper plug-ins (platform + process +
dynamic loader + os plug-in + abi) get selected.

So if you started your LLDB with:

% lldb --arch vliw-<vendor>-<os> a.out

We can select the correct plugins. Is there a vendor and os for the VLIW
target? If not, you can always specify "vliw-unknown-unknown" which means,
no vendor and no OS, and this can still help the plug-ins to determine which
plug-ins will be selected.

No and hence I shall specify "vliw-unknown-unknown". And in this case,
i saw the lldb taking the PlatformLinux plugin.

>
> Doubt: Under the Platform plug-in, I see there is a folder "gdb-server".
> I don't understand the significance of this. Should I consider this for my
> case?

Not unless you want to implement a "lldb-platform" plug-in that runs on
the VLIW simulator that implements all of the functionality of the Platform
plug-ins.

>
> 4. ABI refers to the target architecture description such as the
> register information, call frame information etc. So I have to create a
> class for my VLIW architecture (which is a sub-class of lldb_private::ABI).

ABI is for calling convention stuff like when making function calls with
simple arguments, where (which register or stack offset) will the arguments
be? Also what name mangling is used for the VLIW ABI? If it is the Itanium,
you can probably subclass the existing Itanium ABI plug-in for VLIW.

>
> 5. Process refers to the module that connects lldb to the remote module.
> lldb has gdb-remote already supported. And hence I am not required to do
> anything on this.
>
> Can someone help me to go further on this?

If your simulator supports the GDB remote protocol, you should be ready to
try and connect once you get the "vliw" architecture added to LLVM and into
LLDB.

As said above my simulator supports the GDB remote protocol. Also the
"vliw" architecture has llvm supported already.

I added the "vliw" architecture to the lldb. (Updated the files -
lldb/Core/ArchSpec.h, lldb/lib/Makefile, llvm/tools/source/lldb.cpp.
Added Plugins/ABI/SysV-vliw)

Now on running "lldb --arch vliw app.elf" I get the following error:

error: '/home/chandra/app01/workplace/app.elf' doesn't contain the
architecture vliw

On debugging I found the error is while resolving the executable

-- cut --

if (exe_arch.IsValid())
{
    error = ModuleList::GetSharedModule (resolved_exe_file,
           exe_arch,
           NULL,
           NULL,
           0,
           exe_module_sp,
           NULL,
           NULL);

    if (exe_module_sp->GetObjectFile() == NULL)
    {
  exe_module_sp.reset();
  error.SetErrorStringWithFormat ("'%s%s%s' doesn't contain the architecture %s",
          exe_file.GetDirectory().AsCString(""),
          exe_file.GetDirectory() ? "/" : "",
          exe_file.GetFilename().AsCString(""),
          exe_arch.GetArchitectureName());
    }
}

-- cut --
file: lldb/source/Plugins/Platform/Linux/PlatformLinux.cpp
Method: PlatformLinux::ResolveExecutable()

I am further checking with the method "ModuleList::GetSharedModule ()".

Is there something i could have missed with lldb porting?

Thank you. I worked further with your guidance. Kindly see my response
embedded below.

> Hi,
>
> I am to port lldb for a VLIW architecture. I am entirely new to lldb.
> But have some experience in porting gdb for the same architecture.
>
> Somemore insight on my problem of porting lldb for the VLIW
> architecture. The lldb is to connect the (VLIW architecture) simulator
> remotely. Both the lldb and the simulator are to run on the linux machine.
> (the host machine is the linux machine - Ubuntu).
>
> The simulator already has the RSP server support with it (which already
> worked well with my 'gdb port for this architecture'). Now I want lldb in
> place of gdb.

When you say "The simulator already has the RSP server support", does this
mean the port implements the GDB remote protocol? Or a custom debug
protocol?

Yes, simulator implements the GDB remote protocol.

>
> On searching for a starting point on lldb port, I found very few
> references in the form of few mails at lldb-dev mailing list.
>
> lists.cs.uiuc.edu/pipermail/lldb-dev/2012-January/000770.html
>
> With this I got the below understanding on my lldb porting tasks to that
> VLIW architecture.
>
> 1. To port lldb for the VLIW architecture, it is must to have the llvm
> ported to that VLIW architecture. This is because lldb uses few modules of
> llvm for some functionalities such as expressions evaluation, disassembling.

Yes.

> 2. With llvm ported for the VLIW architecture, in my case following are
> the lldb modules I have to consider for porting:
> a. Platform plug-in
> b. ABI plug-in
> c. Process plug-in

Yes, unless the port to your simulator uses the GDB remote protocol, it
which case you can skip step 'c' above. If your simulator does implement the
GDB remote protocol, let me know, else, you will need to subclass
"lldb_private::Process" into a new process plug-in. This plug-in will also
subclass lldb_private::Thread.

My simulator implements the GDB remote protocol. So I can skip step 'c'.

>
> 3. Platform refers to the host OS on which the lldb runs. In my case I
> am to run the lldb on linux platform. And since lldb has the support for
> linux platform, I am not required to do anything on this.

Platform plug-ins do a few things:
- locate paths for files mentioned during a remote debug session.
- locate debug symols for executable files (in case they are separate)
- upload/download files
- install applications (which is an extension of uploading a file as you
might have to register the application with the OS)
- list processes
- attach and launch processes
- more

The main thing to note is if you have version 1.2.3 of linux on your local
machine and you debug a binary on a 2.3.4 version of linux, you might be
asked to locate "/usr/lib/libfoo.so" on your system. If you have a complete
copy of the binaries on your local system for the remote 2.3.4 machine, the
platform plug-in will be responsible for mapping "/usr/lib/libfoo.so" to
"/users/jsmith/src/linux/2.3.4/root/usr/lib/libfoo.so".

The platform also gets to state which architectures it supports so that
the platform can be auto selected when given a binary that doesn't match the
current host. For example:

% lldb --arch armv6 a.out
Current executable set to 'a.out' (armv6).
(lldb) target list
Current targets:
* target #0: /Volumes/work/gclayton/Documents/devb/attach/a.out (
arch=armv6-apple-ios, platform=remote-ios )

This was run on an x86_64 Mac, but since the binary "a.out" didn't contain
"x86_64" or "i386" architectures, LLDB used the currently installed
platforms to determine which platform to use. In this case it was
"remote-ios". It knew this becauase the "remote-ios" is the only platform
that supports the arm architecture currently. The target triple can be
further filled out to ensure the propper plug-ins (platform + process +
dynamic loader + os plug-in + abi) get selected.

So if you started your LLDB with:

% lldb --arch vliw-<vendor>-<os> a.out

We can select the correct plugins. Is there a vendor and os for the VLIW
target? If not, you can always specify "vliw-unknown-unknown" which means,
no vendor and no OS, and this can still help the plug-ins to determine which
plug-ins will be selected.

No and hence I shall specify "vliw-unknown-unknown". And in this case,
i saw the lldb taking the PlatformLinux plugin.

>
> Doubt: Under the Platform plug-in, I see there is a folder "gdb-server".
> I don't understand the significance of this. Should I consider this for my
> case?

Not unless you want to implement a "lldb-platform" plug-in that runs on
the VLIW simulator that implements all of the functionality of the Platform
plug-ins.

>
> 4. ABI refers to the target architecture description such as the
> register information, call frame information etc. So I have to create a
> class for my VLIW architecture (which is a sub-class of lldb_private::ABI).

ABI is for calling convention stuff like when making function calls with
simple arguments, where (which register or stack offset) will the arguments
be? Also what name mangling is used for the VLIW ABI? If it is the Itanium,
you can probably subclass the existing Itanium ABI plug-in for VLIW.

>
> 5. Process refers to the module that connects lldb to the remote module.
> lldb has gdb-remote already supported. And hence I am not required to do
> anything on this.
>
> Can someone help me to go further on this?

If your simulator supports the GDB remote protocol, you should be ready to
try and connect once you get the "vliw" architecture added to LLVM and into
LLDB.

As said above my simulator supports the GDB remote protocol. Also the
"vliw" architecture has llvm supported already.

I added the "vliw" architecture to the lldb. (Updated the files -
lldb/Core/ArchSpec.h, lldb/lib/Makefile, llvm/tools/source/lldb.cpp.
Added Plugins/ABI/SysV-vliw)

Now on running "lldb --arch vliw app.elf" I get the following error:

error: '/home/chandra/app01/workplace/app.elf' doesn't contain the
architecture vliw

On debugging I found the error is while resolving the executable

-- cut --

if (exe_arch.IsValid())
{
    error = ModuleList::GetSharedModule (resolved_exe_file,
                                         exe_arch,
                                         NULL,
                                         NULL,
                                         0,
                                         exe_module_sp,
                                         NULL,
                                         NULL);

    if (exe_module_sp->GetObjectFile() == NULL)
    {
        exe_module_sp.reset();
        error.SetErrorStringWithFormat ("'%s%s%s' doesn't contain the architecture %s",
                                        exe_file.GetDirectory().AsCString(""),
                                        exe_file.GetDirectory() ? "/" : "",
                                        exe_file.GetFilename().AsCString(""),
                                        exe_arch.GetArchitectureName());
    }
}

-- cut --
file: lldb/source/Plugins/Platform/Linux/PlatformLinux.cpp
Method: PlatformLinux::ResolveExecutable()

I am further checking with the method "ModuleList::GetSharedModule ()".

Is there something i could have missed with lldb porting?

I fixed this. Actually there was a problem with the e_machine name
with my elf file.

And now on running the lldb,

lldb --arch vliw /home/chandra/app01/workplace/app.elf
Current executable set to '/home/chandra/app01/workplace/app.elf' (vliw).
(lldb) target list
Current targets:
* target #0: /home/chandra/app01/workplace/app.elf (
arch=vliw-pc-linux-gnu, platform=localhost )

I see the platform selected is being shown as "localhost". I hope the
platform selected should be "PlatformLinux".

And I face error on connecting the lldb with the simulator.

(lldb) process connect connect://localhost:51000
error: remote connections are not supported

I fixed this. Actually there was a problem with the e_machine name
with my elf file.

And now on running the lldb,

lldb --arch vliw /home/chandra/app01/workplace/app.elf
Current executable set to '/home/chandra/app01/workplace/app.elf' (vliw).
(lldb) target list
Current targets:
* target #0: /home/chandra/app01/workplace/app.elf (
arch=vliw-pc-linux-gnu, platform=localhost )

I see the platform selected is being shown as "localhost". I hope the
platform selected should be "PlatformLinux".

And I face error on connecting the lldb with the simulator.

(lldb) process connect connect://localhost:51000
error: remote connections are not supported

This is probably because you have the PlatformLinux selected and it is trying to connect to the current host linux in order to debug your program.

If you don't have any specific platform needs (no special needs in locating files, executables, upload/download files, etc) then you probably want no platform plug-in selected, or make one up for VLIW. You are having trouble launching because the local linux platform is selected and it is trying to debug your program on the current linux host.

When you create a target TargetList::CreateTarget() is called. It will try and find an platform that goes with your executable and the triple you specified. You want to step through this code and make sure that when "PlatformLinux::CreateInstance()" is called, that it doesn't claim it is the appropriate platform for your executable.

To work around the issues above, first you want to launch lldb (or "target create") with a full triple:

lldb --arch vliw-unknown-unknown /home/chandra/app01/workplace/app.elf

Then you can specify the process plug-in to use:

(lldb) process connect --plugin gdb-remote connect://localhost:51000

If you specify the "gdb-remote" plug-in by name, you won't end up trying to launch with the "ProcessLinux" plug-in which doesn't support remote connections. It will use the ProcessGDBRemote plugin.

Let me know if this help/works.

Greg Clayton

To work around the issues above, first you want to launch lldb (or "target create") with
a full triple:

lldb --arch vliw-unknown-unknown /home/chandra/app01/workplace/app.elf

Then you can specify the process plug-in to use:

(lldb) process connect --plugin gdb-remote connect://localhost:51000

If you specify the "gdb-remote" plug-in by name, you won't end up trying to launch with
the "ProcessLinux" plug-in which doesn't support remote connections. It will use the
ProcessGDBRemote plugin.

Let me know if this help/works.

We did as you said above. And we faced following error as shown below:

$lldb --arch vliw-unknown-unknown /home/chandra/app01/workplace/app.elf
Current executable set to '/home/chandra/app01/workplace/app.elf' (vliw).
(lldb) process connect --plugin gdb-remote connect://localhost:51000
error: Unable to find process plug-in for remote URL 'process connect'.
Please specify a process plug-in name with the --plugin option, or
specify an object file using the "file" command.

For resolving the above error, we included the following line in
method "lldb_private::Initialize ()"

- ProcessGDBRemote::Initialize();

Now the connection is established. But the process exits immediately
as shown below:

$lldb --arch vliw-unknown-unknown /home/chandra/app01/workplace/app.elf
Current executable set to '/home/chandra/app01/workplace/app.elf' (vliw).
(lldb) process connect --plugin gdb-remote connect://localhost:51000
Process 1 exited with status = -1 (0xffffffff) lost connection

This is because, after establishing the connection, lldb sends the 'c'
packet to the gdb server (with the simulator). Which in-turn executes
the application in the simulator.

I have given the communication between lldb and gdb server (with the simulator).

Send Packet: QThreadSuffixSupported
Read Packet:
Send Packet: qHostInfo
Read Packet: cputype:201;cpusubtype:-2;ostype:unknown;vendor:unknown;endian:little;ptrsize:4;
Send Packet: vCont?
Read Packet:
Send Packet: qC
Read Packet: QC1
Send Packet: ?
Read Packet: S00
Send Packet: qRegisterInfo0
Read Packet: name:r0;alt-name:sp;bitsize:32;offset:0;encoding:uint;format:hex;set:General
Purpose Registers;gcc:0;dwarf:0;generic:sp;
Send Packet: qRegisterInfo1
Read Packet: name:r1;alt-name:RT;bitsize:32;offset:8;encoding:uint;format:hex;set:General
Purpose Registers;gcc:1;dwarf:1;generic:ra;
Send Packet: qRegisterInfo2
Read Packet: name:r2;alt-name:P0;bitsize:32;offset:16;encoding:uint;format:hex;set:General
Purpose Registers;gcc:2;dwarf:2;generic:arg1;
..
..
..
Send Packet: qRegisterInfo53
Read Packet: name:r83;alt-name:NPC;bitsize:32;offset:664;encoding:uint;format:hex;set:General
Purpose Registers;gcc:83;dwarf:83;generic:pc;
Send Packet: qRegisterInfo54
Read Packet: E45
Send Packet: qfThreadInfo
Read Packet: m1
Send Packet: qsThreadInfo
Read Packet: l
Send Packet: qThreadStopInfo1
Unrecognized packet: ignored
Send Packet: Hg1
Read Packet: OK
Send Packet: p53
Read Packet: 08010120
Send Packet: Hc-1
Read Packet: OK
Send Packet: c <=========== this enables the application
execution on simulator

I hope 'process connect' is to establish the remote connection. And it
should wait for further commands (break-point, run etc.).

But here it starts the execution of the application.

Now I am analyzing on this. Could you please help me on this?

The problem stems from the "S00" being returned in response to the "?" packet. If you can return "S11" for the first stop, this should fix your issue. The problem is the "S00" currently means "there is no important reason why we stopped". Usually the debugger only stops due to a breakpoint, exception, watchpoint, exit, or other exceptional event. So currently when you stop for no apparent reason, we just continue. If it is hard to return "S11" only for the first stop, you can always return it until you can provide a better stop reply packet with more info. An example stop reply packet from x86_64 is:

$T11thread:1c03;qaddr:a0;threads:1c03;02:0000000000000000;03:0000000000000000;04:0000000000000000;05:0000000000000000;06:0000000000000000;07:40f8bf5fff7f0000;08:0000000000000000;09:0000000000000000;10:2810c05fff7f0000;11:0002000000000000;metype:5;mecount:2;medata:10003;medata:11;#00

Breaking this down:

# Stop for thread with signal SIGSTOP
T11

# The thread this stop info is for
thread:1c03;

# the full thread list in stop reply which is enabled by replying "OK" to "QListThreadsInStopReply"
threads:1c03;

# expedited register values
02:0000000000000000;
03:0000000000000000;
04:0000000000000000;
05:0000000000000000;
06:0000000000000000;
07:40f8bf5fff7f0000;
08:0000000000000000;
09:0000000000000000;
10:2810c05fff7f0000;
11:0002000000000000;

# mach specific exception info that no one else needs to emit
metype:5;
mecount:2;
medata:10003;
medata:11;

#00

So try using "S11" to start with, but quickly transition over to using "T11thread:XXXX;key:value;..." if you can

So try using "S11" to start with, but quickly transition over to using "T11thread:XXXX;key:value;..." if you can

I went with "T11thread:XXXX;..". It worked. Thanks a lot.