This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Add support for the x86 XSAVE extended state on FreeBSD/x86.
- From: John Baldwin <jhb at FreeBSD dot org>
- To: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Cc: palves at redhat dot com, gdb-patches at sourceware dot org
- Date: Sat, 21 Mar 2015 18:28:58 -0400
- Subject: Re: [PATCH] Add support for the x86 XSAVE extended state on FreeBSD/x86.
- Authentication-results: sourceware.org; auth=none
- References: <2672674 dot t3ZJOKnpzU at ralph dot baldwin dot cx> <5509D93A dot 5030707 at redhat dot com> <550DC328 dot 40800 at FreeBSD dot org> <201503212018 dot t2LKI3jm000615 at glazunov dot sibelius dot xs4all dot nl>
On 3/21/15 4:18 PM, Mark Kettenis wrote:
>> That could be reused for the core read_description callback as
>> well as the native ones. This could also be reused by other
>> systems that grow XSAVE support in the future.
>
> Probably a good idea. I'm working on XSAVE support in the OpenBSD
> kernel, so I'll eventually need this as well.
>
> I have no real objection to adding the ptrace-specific bits to the
> generic BSD native code like your diff is doing. I'll probably try to
> use the same interface for my OpenBSD implementation. I have one
> concern about that code though. The _supply_xsave() and
> _collect_xsave() functions don't accept a length, so they can't do any
> bounds checking. Therefore, 'xstat_bv' as returned by the kernel must
> be set correctly (i.e. not have bits sets that imply state beyond
> x86_save_len is present. Does the FreeBSD kernel guarantee that?
FreeBSD determines a system-wide xsave mask during boot and then leaves
%xcr0 unchanged. The x86_xstate_len returned by PT_GETXSTATE_INFO is
also determined at boot time and doesn't change after that. The kernel
does assume that xsave/xsaveopt do not store any bits in xstate_bv that
aren't set in %xcr0. Attempts to restore a saved state via PT_SETXSTATE
that set a bit in xstate_bv that isn't set in %xcr0 results in
PT_SETXSTATE failing. Those should ensure that xstate_bv does not
return an invalid length.
However, we could do additional bounds checking in the routines in
*bsd-nat.c by making them compare X86_XSTATE_SIZE(xstate_bv) against
x86_xstate_len and fail if x86_xstate_len is too small.
> Oh, and please rename x86_xsave_len into amd64bsd_xsave_len and
> i386bsd_xsave_len to keep the "namesapce" clean.
Will do.
--
John Baldwin