Weird host vs process combi in lldb / gdb server combi

When connecting to an iPad mini (that doesn't support armv7s) I get these process vs host results:

Process: armv7s-apple-ios
Host: armv7f-apple-ios

now I might have misunderstood what the gdb process info is supposed to to but I thought host is what the device itself runs, and process is the 'cpu type' of the process.

  remote_process_arch {m_triple={Data="armv7s-apple-ios" Arch=arm (1) Vendor=Apple (1) ...} m_core=eCore_arm_armv7s (9) m_byte_order=...}

  remote_host_arch {m_triple={Data="armv7f-apple-ios" Arch=arm (1) Vendor=Apple (1) ...} m_core=eCore_arm_armv7f (8) m_byte_order=...}

Am I wrong in this, or what's going on here?

Unlike other systems, Apple ARM binaries can run the best universal slice for the job. The kernel can be "armv7s", and when shared libraries are loaded the system will try "armv7s" first, then "armv7", then "armv6", etc etc.

Did you specify a starting architecture with the "target create" or "file" command? If you didn't you should be able to fix this by specifying the right architecture up front with the "file" command. If you did specify it, we will listen to what you specified. If you didn't specify anything, the "file" command will try and select the right architecture for you and it might have incorrectly specified "armv7f"...

To see what was select, you can run "target list":

(lldb) file /path/to/binary/a.out
(lldb) target list

It will show you the architecture it "auto" selected for you. If you want to force "armv7s", then specify it:

(lldb) file --arch armv7s-apple-ios /path/to/binary/a.out
(lldb) target list