Converts the MAP_PRIVATE and MAP_ANON options to the target platform constants (on which the call runs) rather than using those of the compiled host.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Looking up the mmap function address from the symbol table seems to have started working - we should still load debug symbols when possible but that can be done in a separate change.
This change is pretty much the minimal required to get this working. The process is a ProcessGDBRemote, and the platform is a PlatformRemoteGDBServer so I think we still need to check the target architecture if we try to move this to the process / platform.
If you do a "platform select remote-linux", the platform is (or should be) PlatformLinux, which contains a PlatformRemoteGDBServer as a member and then proxies all the operations to it, if it does not want special handling. E.g., PlatformLinux::GetProcessInfo is implemented like
if (IsHost()) { success = Platform::GetProcessInfo (pid, process_info); } else { if (m_remote_platform_sp) success = m_remote_platform_sp->GetProcessInfo (pid, process_info); // This is a PlatformRemoteGDBServer }
So I think you should be able to thread your handling through the platform.
- Delegate to Platform to convert Mmap flags.
- Fix platform when running remote-linux from mac by hard-coding linux archs, previously used host binary arch spec (e.g. macosx when running from mac)
Okay, I had to hard-code the archs on Linux rather than use the host arch spec so that the PlatformLinux was considered "compatible" with the Linux target (previously was using the host arch - macosx). It looks like lots of the Platform::GetSupportedArchAtIndex use the host OS, which seems like the wrong thing to do when you may be targetting that platform as a remote platform - perhaps we should be hard-coding the arch specs of other OS's as well.
I added the convert method to Platform.h and everything seems to be working.