- Dump an NT_X86_XSTATE note if XSAVE is in use. This note is designed
to match what Linux does in that 1) it dumps the entire XSAVE area
including the fxsave state, and 2) it stashes a copy of the current
xsave mask in the unused padding between the fxsave state and the
xstate header at the same location used by Linux.
- Teach readelf() to recognize NT_X86_XSTATE notes.
- Change PT_GET/SETXSTATE to take the entire XSAVE state instead of
only the extra portion. This avoids having to always make two
ptrace() calls to get or set the full XSAVE state.
- Add a PT_GET_XSTATE_INFO which returns the length of the current
XSTATE save area (so the size of the buffer needed for PT_GETXSTATE)
and the current XSAVE mask (%xcr0).
Differential Revision: https://reviews.freebsd.org/D1193
Reviewed by: kib
MFC after: 2 weeks
is in accordance with the information provided at
ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change
Also add $FreeBSD$ to a few files to keep svn happy.
Discussed with: imp, rwatson
thread specific informations.
In order to do that, and in order to avoid KBI breakage with existing
infrastructure the following semantic is implemented:
- For live programs, a new member to the PT_LWPINFO is added (pl_tdname)
- For cores, a new ELF note is added (NT_THRMISC) that can be used for
storing thread specific, miscellaneous, informations. Right now it is
just popluated with a thread name.
GDB, then, retrieves the correct informations from the corefile via the
BFD interface, as it groks the ELF notes and create appropriate
pseudo-sections.
Sponsored by: Sandvine Incorporated
Tested by: gianni
Discussed with: dim, kan, kib
MFC after: 2 weeks
default invokation):
- Right now if segments are not writable are not included. Remove this.
- Right now if a segment is mapped with NOCORE the check is not honoured.
Change this by checking the newly added flag, from libutil,
KVME_FLAG_NOCOREDUMP.
Besides that, add a new flag (-f) that forces a 'full' dump of all the
segments excluding just the malformed ones. This might be used very
carefully as, among the reported segments, there could be memory
mapped areas that could be vital to program execution.
Sponsored by: Sandvine Incorporated
Discussed with: kib
Reviewed by: emaste
Tested by: Sandvine Incorporated
MFC after: 2 weeks
specific sysctls and ptrace interfaces.
This change switches a bit gcore POLA that is summarized here:
- now gcore can recognize threads within the process and handle dumps
on thread-scope
- the process to be analyzed will be stopped during its gcore run
- gcore may not work with processes which are actively being analyzed
by gdb or truss
- the ptrace interface may cause syscalls to return EINTR, thus
interferring with signals handling within the process
Side note: <janitor task> the interface can be further lifted in order to
get rid of the very last procfs interfaces remnants and made more
suitable for copying with sysctl/ptrace interface </janitor task>.
Obtained from: Sandvine Incorporated
Reviewed by: emaste, rwatson
Sponsored by: Sandvine Incorporated
MFC: 1 month
using sscanf and truncating the start/end entries by writing them with a
32 bit int descriptor (%x). The upper bytes of the 64 bit vm_offset_t
variables (for little endian machines) were uninitialized. For big endian
machines, things would have been worse because it was storing the 32 bit
value in the upper half of the 64 bit variable. I've changed it to use
%lx and long types. That should work on all our platforms.
file so that we have a chance of using gcore on non-i386 platforms. Use
linker sets to reduce the registration glue. Remove md-sparc.c, we do not
have an a.out sparc32 port. aoutcore.c was repocopied from gcore.c.
Add some constness to avoid some warnings.
Remove use register keyword.
Deal with missing/unneeded extern/prototypes.
Some minor type changes/casts to avoid warnings.
Reviewed by: md5
Note ALL MODULES MUST BE RECOMPILED
make the kernel aware that there are smaller units of scheduling than the
process. (but only allow one thread per process at this time).
This is functionally equivalent to teh previousl -current except
that there is a thread associated with each process.
Sorry john! (your next MFC will be a doosie!)
Reviewed by: peter@freebsd.org, dillon@freebsd.org
X-MFC after: ha ha ha ha
longer includes machine/elf.h.
* consumers of elf.h now use the minimalist elf header possible.
This change is motivated by Binutils 2.11.0 and too much clashing over
our base elf headers and the Binutils elf headers.