Greg Clayton wrote:
A few questions:
In PlatformKalimba::GetProcessInfo() the code is:
PlatformKalimba::GetProcessInfo (lldb::pid_t pid, ProcessInstanceInfo &process_info)
bool success = false;
success = Platform::GetProcessInfo (pid, process_info);
success = m_remote_platform_sp->GetProcessInfo (pid, process_info);
Can "kalimba" processes actually run locally on your host machine as native apps? I would guess that PlatformKalimba is for remote debugging only and would expect your code to return false if "IsHost()" is true in that case. If you are running a simulator that uses local processes on the host machine, then this is correct.
We can't run kalimba ELFs on the host. We do have a simulator (which acts on a file resulting from turning an ELF into a bespoke target memory view) to run on the host, but we'd connect to the sim, in the "same" way as a real device, except that the CSR-type SPI wire packets, move over TCP/IP not on a real wire as such. So debugging kalimba on a simulator is still remote debugging. I'll modify my implementation as follows:
bool success = false;
- success = Platform::GetProcessInfo (pid, process_info);
+ success = false;
which I believe to be your suggestion.
In your GetSupportedArchitectureAtIndex you should only return true if "idx == 0":
PlatformKalimba::GetSupportedArchitectureAtIndex (uint32_t idx, ArchSpec &arch)
if (idx == 0)
arch = ArchSpec("kalimba-csr-unknown");
GetSupportedArchitectureAtIndex gets used when you select your platform and then load an executable. It will search for valid architectures by iterating through the architectures using an increasing index. This is needed for cases like iOS where the iOS device might be "armv7s", but when we load a binary, we will start with "armv7s" and then back up to looking for "armv7", armv6", etc.
Ok, thanks for this, I'll modify my next patch attempt accordingly.
You will need to fill out:
PlatformDarwin::GetSoftwareBreakpointTrapOpcode (Target &target, BreakpointSite *bp_site)
You mainly need to figure out which opcode your target will use as a breakpoint instruction and return its size and fill in the bytes for the instruction, see PlatformDarwin::GetSoftwareBreakpointTrapOpcode() for an example.
Software breakpoints aren't properly supported on kalimba. We did have them in the earlier variants, but I'm told that these never worked well: there were issues in the pipeline implementation and so on.
So I think that my original implementation of "return 0" was correct.
Kalimba architectures do, however, support setting up to 8 hardware breakpoints. That is, we have dedicated debug registers in the hardware.
By the way what sort of thing should PlatformKalimba do for CalculateTrapHandlerSymbolNames? Should that be a no-op, not a m_trap_handlers.push_back (ConstString ("_sigtramp"));?
In PlatformKalimba::LaunchProcess() you end up launching a host process after checking IsHost(), is this your intention? Are you running a simulator?
Ok. So is it correct to merely do something like this:
error.SetErrorString ("native execution is not possible");
Same thing for PlatformKalimba::Attach().
Ok. So I'll make a similar change to the one made to LaunchProcess.
In response to Greg's review and my current thoughts I'm attaching the latest version of the PlatformKalimba.cpp. Is this file now a good enough first attempt? Or are there any further areas to complete?
In summary I've
1. Modified GetProcessInfo to return false if IsHost()==true.
2. Implemented GetSupportedArchitectureAtIndex as per Greg's suggestion.
3. Modified LaunchProcess and Attach to merely set up an error if IsHost()==true.
4. Retained my previous implementation for GetSoftwareBreakpointTrapOpcode with reasoning.
5. Remove m_trap_handlers.push_back (ConstString ("_sigtramp")); from CalculateTrapHandlerSymbolNames.
I look forward to further comment.
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, Qualcomm Technology News & Trends | Qualcomm, CSR people blog, www.csr.com/people, YouTube, CSR Decomission - YouTube, Facebook, Facebook, or follow us on Twitter at www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com.
PlatformKalimba.cpp (9.86 KB)