[lldb-dev] Load fat executable when uncertain about the target process' architecture

[Carlo Kok]

Greg Clayton schreef op 10/10/2013 7:00 PM:
>
> On Oct 10, 2013, at 8:13 AM, Carlo Kok <ck at remobjects.com> wrote:
>
>> I use:
>> m_target = m_debugger.CreateTarget(fn, archd, NULL, true, m_error);
>> m_process = m_target.ConnectRemote(SBListener(), target, NULL, m_error);
>>
>> (fn points to an executable with x86 and x86_64 in it. archd this x86_64-apple-ios)
>>
>> However the target ends up being a 32bits process. At this point the ABI code loads 64bits and ends up crashing in some 64bits register loading code in ABISysV_x86_64.h:
>>
>> argument_register_ids[0] = reg_ctx->GetRegisterInfoByName("rdi", 0)->kinds[eRegisterKindLLDB];
>>
>>
>> the problem I'm having is that I don't know what architecture the target will be before connecting. Passing no arch to CreateTarget gives this error:
>>
>> "'App10' doesn't contain any 'ios-simulator' platform architectures"
>>
>> I do know GDB has (and gets called for) a command that asks the process architecture, but this doesn't seem to be used to get the abi (and probably more things), what can I do in this case?
>
> The key issue that is going wrong here is you are not specifying a
> platform. If you know you are going to be doing remote macosx
> debugging, then you can tell the target this when you create it. The
> 3rd argument (NULL) in CreateTarget is the platform name. Try
> specifying "remote-macosx".

I'm targeting iOS-Simulator actually. The x86 vs x86_64 difference is 
because the simulator starts a different one based on what kind of 
simulator is running at the moment. Remote-macosx doesn't support the 
simulator. It works if I run & pass x86_64 or i386, but in this case I 
don't know what's running (there doesn't seem to be a way to detect it) 
and I just pass the "best" I compiled (x86_64) but it's running in 
32bits mode so runs the i386 side of it, then fails.

I tried ios-remote too (with a null platform) but that makes it just 
load the i386 part of my fat executable (when reading a fat binary it 
somehow picks the first one if none was specified and I can't find a way 
to delay this choice until it's connected).



-- 
Carlo Kok
RemObjects Software