Date: Tue, 28 Mar 2017 11:26:43 -0700 From: John Baldwin <jhb@freebsd.org> To: mmel@freebsd.org Cc: Warner Losh <imp@bsdimp.com>, src-committers <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r315974 - in head: lib/libthread_db/arch/arm sys/arm/arm sys/arm/include Message-ID: <22618548.zXcKfQPOV0@ralph.baldwin.cx> In-Reply-To: <74bb4fb0-b5d5-4be4-bcfe-4be343c2aee7@freebsd.org> References: <201703260836.v2Q8auoU069005@repo.freebsd.org> <CANCZdfoFqCEXQVM%2BbbRBiDqiajck5qmoonWfAC7xwYAcJq488Q@mail.gmail.com> <74bb4fb0-b5d5-4be4-bcfe-4be343c2aee7@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, March 28, 2017 12:20:04 PM Michal Meloun wrote: > > On 27.03.2017 19:40, Warner Losh wrote: > > On Mon, Mar 27, 2017 at 11:07 AM, John Baldwin <jhb@freebsd.org> wrote: > >> On Sunday, March 26, 2017 08:36:56 AM Michal Meloun wrote: > >>> Author: mmel > >>> Date: Sun Mar 26 08:36:56 2017 > >>> New Revision: 315974 > >>> URL: https://svnweb.freebsd.org/changeset/base/315974 > >>> > >>> Log: > >>> Preserve VFP state across signal delivery. > >>> > >>> We don't have enouch space to store full VFP context within mcontext > >>> stucture. Due to this: > >>> - follow i386/amd64 way and store VFP state outside of the mcontext_t > >>> but point to it. Use the size of VFP state structure as an 'magic' > >>> indicator of the saved VFP state presence. > >>> - teach set_mcontext() about this external storage. > >>> - for signal delivery, store VFP state to expanded 'struct sigframe'. > >>> > >>> Submited by: Andrew Gierth (initial version) > >>> PR: 217611 > >>> MFC after: 2 weeks > >>> > >>> Modified: > >>> head/lib/libthread_db/arch/arm/libpthread_md.c > >>> head/sys/arm/arm/machdep.c > >>> head/sys/arm/include/frame.h > >>> head/sys/arm/include/ucontext.h > >>> > >>> Modified: head/lib/libthread_db/arch/arm/libpthread_md.c > >>> ============================================================================== > >>> --- head/lib/libthread_db/arch/arm/libpthread_md.c Sun Mar 26 08:36:20 2017 (r315973) > >>> +++ head/lib/libthread_db/arch/arm/libpthread_md.c Sun Mar 26 08:36:56 2017 (r315974) > >>> @@ -90,7 +90,9 @@ pt_fpreg_to_ucontext(const struct fpreg > >>> mcontext_t *mc = &uc->uc_mcontext; > >>> > >>> /* XXX */ > >>> - memset(&mc->mc_spare, 0, sizeof(mc->mc_spare)); > >>> + mc->mc_vfp_size = 0; > >>> + mc->mc_vfp_ptr = NULL; > >>> + memset(mc->mc_spare, 0, sizeof(mc->mc_spare)); > >>> } > >> I suspect you don't need this bit? Has FreeBSD/arm ever supported VFP on a release > >> that also shipped libkse? (i.e. not libthr but the other thread library) > > No. And even if we had, we blew up binary compat when we went from OABI to EABI. > > > > Warner > I just wanted to maintain the status quo, nothing more. > > All I know is that none of threading libraries maintains VFP state, > 'struct fpreg' is badly defined (is to short for fill VFP context), and > pre r315974 kernel doesn't initialize _vfp (renamed to mc_spare) part > of mcontext_t. > > So I'm seeking a way how to fix all this. But I'm not familiar with > kse -> pthread transition history, so I'm not sure which parts are > actively used. The libpthread_md.c files are for the KSE-based libpthread and generally don't need changing at this point as they are only there to allow old gdb binaries to debug old binaries using libpthread. In particular, with the KSE thread library, a "paused" user thread that wasn't associated with a kernel thread ("LWP") needed it's userland register state saved somewhere until it resumed execution. The libpthread bits are for extracting that saved register state so a debugger can examine a non-running user thread. Modern gdb in ports doesn't use libthread_db at all, and I think lldb might not use it either. (Both just assume that every pthread has an associated LWP and use ptrace() to query information about LWPs directly). Note that on x86 we haven't updated any of the libthread_db stuff to handle newer vector register extensions like AVX. That only works via direct ptrace() for example. It will be good to include VFP info in cores via new core notes (if not done already) and to provide a way to fetch the register banks from a running thread via ptrace, but you can generally ignore libthread_db. At some point gdb in ports might use some small bits of libthread_db to determine the pthread_t associated with a kernel-enumerated LWP, but that's about all it would ever be used for at this point. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?22618548.zXcKfQPOV0>