[Lldb-commits] [lldb] r186207 - Introduces core file support for Linux x86-64 using 'lldb a.out -c core'.

[Greg Clayton]

On Jul 25, 2013, at 11:41 AM, Ed Maste <emaste at freebsd.org> wrote:

> On 16 July 2013 17:43, Greg Clayton <gclayton at apple.com> wrote:
>> I spent some time modifying the patch to correctly abstract the register contexts so we don't have this incorrect RegisterContext base class that uses ProcessMonitor... I wasn't able to finish it, but I did get it close. I have attached the patch for you guys to check out and hopefully fix it up and get it working for normal linux/freebsd, and for ELF core files for both linux and freebsd.
>> 
>> The basics are, the following classes contain the register context data, but don't do any of the reading/writing registers (they have pure virtual functions for that):
>> 
>> RegisterContextPOSIX_i386
>> RegisterContextPOSIX_x86_64
> 
> Is there any reason these shouldn't be just RegisterContext_i386 and
> RegisterContext_x86_64, and used for all platforms (i.e., shared with
> the Darwin ones)?

Yes, different systems expose different registers. When you match your local register context to the exact structures that are used by the current system, you can easily read registers and blast them into a buffer with no remapping required. Darwin, for x86_64, has:

struct GPR
{
	__uint64_t	rax;
	__uint64_t	rbx;
	__uint64_t	rcx;
	__uint64_t	rdx;
	__uint64_t	rdi;
	__uint64_t	rsi;
	__uint64_t	rbp;
	__uint64_t	rsp;
	__uint64_t	r8;
	__uint64_t	r9;
	__uint64_t	r10;
	__uint64_t	r11;
	__uint64_t	r12;
	__uint64_t	r13;
	__uint64_t	r14;
	__uint64_t	r15;
	__uint64_t	rip;
	__uint64_t	rflags;
	__uint64_t	cs;
	__uint64_t	fs;
	__uint64_t	gs;
}

Not that many of the segment registers are missing as they are not backed up with each thread. LLDB also requires that all registers be numbered started at zero and increment up with no gaps in between for the register IDs so that lookups are always just a direct access into an array instead of a large switch statement which works arounds the gaps.

The register contexts are easy to subclass and tailor to how your system reads registers (entire register sets at a time, or individual registers). I would like to avoid showing registers that can't be read/written to on a platform (like the segment registers in our case).

Greg