[Lldb-commits] [lldb] r186207 - Introduces core file support for Linux x86-64 using 'lldb a.out -c core'.
gclayton at apple.com
Fri Jul 12 16:04:43 PDT 2013
On Jul 12, 2013, at 3:59 PM, Greg Clayton <gclayton at apple.com> wrote:
> I reverted the ELF core file support until we can get the darwin build working. I could have commented out the initialization in lldb.cpp, but there were changes in AuxVector that used the ELF core file process plug-in name, so the ELF core file process plug-in needed to be compiled in in order to link.
> It seems like we need to cleanup the register context classes to make sure ones that are used under ProcessPOSIX are completely separate from the ones that ProcessElfCore will use. The reverted patch had the base RegisterContext class with a GetMonitor() accessor that required ProcessPOSIX to be compiled in which doesn't work for darwin builds since ProcessPOSIX is only compiled in on systems that natively use it.
Also the base register context class can't have this because the process will either be ProcessPOSIX or ProcessElfCore. If the GetMonitor() function got calls when ProcessElfCore was the process we could have issues.
To work around this on MacOSX, we have a base RegisterContextDarwin_<ARCH> which must be subclassed and it has pure virtual functions:
DoReadGPR (lldb::tid_t tid, int flavor, GPR &gpr) = 0;
DoReadFPU (lldb::tid_t tid, int flavor, FPU &fpu) = 0;
DoReadEXC (lldb::tid_t tid, int flavor, EXC &exc) = 0;
DoWriteGPR (lldb::tid_t tid, int flavor, const GPR &gpr) = 0;
DoWriteFPU (lldb::tid_t tid, int flavor, const FPU &fpu) = 0;
DoWriteEXC (lldb::tid_t tid, int flavor, const EXC &exc) = 0;
The mach core files will override these functions and hook them up to the core file register states, and other targets can do what they need to.
> I will be happy to get the Xcode project building with any additional source files once they build and link for darwin.
> % svn commit
> Sending lib/Makefile
> Sending source/CMakeLists.txt
> Sending source/Plugins/DynamicLoader/POSIX-DYLD/AuxVector.cpp
> Sending source/Plugins/Makefile
> Sending source/Plugins/Process/CMakeLists.txt
> Sending source/Plugins/Process/Linux/ProcessLinux.cpp
> Sending source/Plugins/Process/Linux/ProcessLinux.h
> Sending source/Plugins/Process/POSIX/RegisterContext_x86_64.cpp
> Sending source/Plugins/Process/elf-core/CMakeLists.txt
> Sending source/Plugins/Process/elf-core/Makefile
> Sending source/Plugins/Process/elf-core/ProcessElfCore.cpp
> Sending source/Plugins/Process/elf-core/ProcessElfCore.h
> Sending source/Plugins/Process/elf-core/RegisterContextCoreFreeBSD_x86_64.cpp
> Sending source/Plugins/Process/elf-core/RegisterContextCoreFreeBSD_x86_64.h
> Sending source/Plugins/Process/elf-core/RegisterContextCoreLinux_x86_64.cpp
> Sending source/Plugins/Process/elf-core/RegisterContextCoreLinux_x86_64.h
> Sending source/Plugins/Process/elf-core/ThreadElfCore.cpp
> Sending source/Plugins/Process/elf-core/ThreadElfCore.h
> Sending source/lldb.cpp
> Transmitting file data ...................
> Committed revision 186223.
> On Jul 12, 2013, at 3:30 PM, Greg Clayton <gclayton at apple.com> wrote:
>> RegisterContextCoreLinux_x86_64 inherits from RegisterContextLinux_x86_64 which inherits from RegisterContext_x86_64 which uses has:
>> ProcessMonitor &GetMonitor();
>> This register context used by the core file can't use this since the process plug-in will be ProcessElfCore and the implementation of GetMonitor() does:
>> ProcessMonitor &
>> ProcessSP base = CalculateProcess();
>> ProcessPOSIX *process = static_cast<ProcessPOSIX*>(base.get());
>> return process->GetMonitor();
>> ProcessELFCore doesn't, nor should it inherit from ProcessPOSIX:
>> class ProcessElfCore : public lldb_private::Process
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu
More information about the lldb-commits