[lldb-dev] Weird host vs process combi in lldb / gdb server combi

[Greg Clayton]

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

On Oct 14, 2013, at 7:04 AM, Carlo Kok <ck at remobjects.com> wrote:

> 
> 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?
> 
> -- 
> Carlo Kok
> RemObjects Software
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev