Date: Thu, 2 Aug 2018 10:52:46 -0700 From: John Baldwin <jhb@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Ruslan Bukin <br@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r337127 - head/sys/riscv/riscv Message-ID: <22f6c1e0-11c2-8421-2a27-6ba59ef7b6dc@FreeBSD.org> In-Reply-To: <20180802155030.GA40119@kib.kiev.ua> References: <201808021213.w72CDqQV065424@repo.freebsd.org> <7842b7e4-d14e-805f-719e-b393fc80b74c@FreeBSD.org> <20180802155030.GA40119@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/2/18 8:50 AM, Konstantin Belousov wrote: > On Thu, Aug 02, 2018 at 08:16:59AM -0700, John Baldwin wrote: >> On 8/2/18 5:13 AM, Ruslan Bukin wrote: >>> Author: br >>> Date: Thu Aug 2 12:13:52 2018 >>> New Revision: 337127 >>> URL: https://svnweb.freebsd.org/changeset/base/337127 >>> >>> Log: >>> Don't overwrite tp in set_mcontext(). >>> >>> This makes libthr/swapcontext_test:swapcontext1 happy. >>> >>> Sponsored by: DARPA, AFRL >> >> This seems a bit odd. Is get_mcontext() not setting gp_tp correctly, or is >> makecontext() not preserving it perhaps? >> >> In general I feel like we should be saving/restoring 'tp' in the trapframe >> on kernel entry/exit like other GPRs instead of in the pcb and then >> including it in 'struct reg'. This makes it possible for debuggers to >> handle TLS variables more sanely (and in general we need to fix the various >> struct reg in FreeBSD architectures to include TLS registers when possible, >> such as adding fs_base and gs_base on x86). It would be nice if RISC-V >> started off on the correct foot here. > > I wanted to do this on x86, but I gave up due to the ABI issues. > When FSGSBASE instructions are supported on amd64, we save base > on context switch and restore on return to usermode. For struct reg Linux has done the equivalent of adding fs_base/gs_base if that is the ABI issues. Cores are pretty easy as debuggers can use the note size to determine if fs_base/gs_base are present and old debuggers will just ignore the larger notes. However, PT_GETREGS and PT_SETREGS is more of a pain. Probably we should define a "register set" API for ptrace() which I've been kicking around in my head that includes a way to communicate the size of the register block. I think Linux uses 'data' for it's register set ptrace ops to specify the register size. I think I'd like to be able to use 'data' for the userland size and instead borrow N upper bits in the ptrace op as the register set identifier. Either that or the 'addr' would need to start pointing to an indirect structure when working with a register set. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?22f6c1e0-11c2-8421-2a27-6ba59ef7b6dc>