svn commit: r315974 - in head: lib/libthread_db/arch/arm sys/arm/arm sys/arm/include

John Baldwin jhb at freebsd.org
Tue Mar 28 21:11:13 UTC 2017


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 at 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


More information about the svn-src-all mailing list