src/sys/amd64/include/ptrace.h, branch stable/13

sys: Remove $FreeBSD$: one-line .c comment pattern

2023-08-23T17:43:22Z

Remove /^/[*/]\s*\$FreeBSD\$.*\n/ Similar commit in current: (cherry picked from commit 71625ec9ad2a)

Copy amd64 ptrace.h to x86 and merge with i386 ptrace.h. Replace

2012-03-04T20:24:28Z

amd64/i386/pc98 ptrace.h with stubs. For amd64 PT_GETXSTATE and PT_SETXSTATE have been redefined to match the i386 values. The old values are still supported but should no longer be used. Reviewed by: kib

Add support for the extended FPU states on amd64, both for native

2012-01-21T17:45:27Z

64bit and 32bit ABIs. As a side-effect, it enables AVX on capable CPUs. In particular: - Query the CPU support for XSAVE, list of the supported extensions and the required size of FPU save area. The hw.use_xsave tunable is provided for disabling XSAVE, and hw.xsave_mask may be used to select the enabled extensions. - Remove the FPU save area from PCB and dynamically allocate the (run-time sized) user save area on the top of the kernel stack, right above the PCB. Reorganize the thread0 PCB initialization to postpone it after BSP is queried for save area size. - The dumppcb, stoppcbs and susppcbs now do not carry the FPU state as well. FPU state is only useful for suspend, where it is saved in dynamically allocated suspfpusave area. - Use XSAVE and XRSTOR to save/restore FPU state, if supported and enabled. - Define new mcontext_t flag _MC_HASFPXSTATE, indicating that mcontext_t has a valid pointer to out-of-struct extended FPU state. Signal handlers are supplied with stack-allocated fpu state. The sigreturn(2) and setcontext(2) syscall honour the flag, allowing the signal handlers to inspect and manipilate extended state in the interrupted context. - The getcontext(2) never returns extended state, since there is no place in the fixed-sized mcontext_t to place variable-sized save area. And, since mcontext_t is embedded into ucontext_t, makes it impossible to fix in a reasonable way. Instead of extending getcontext(2) syscall, provide a sysarch(2) facility to query extended FPU state. - Add ptrace(2) support for getting and setting extended state; while there, implement missed PT_I386_{GET,SET}XMMREGS for 32bit binaries. - Change fpu_kern KPI to not expose struct fpu_kern_ctx layout to consumers, making it opaque. Internally, struct fpu_kern_ctx now contains a space for the extended state. Convert in-kernel consumers of fpu_kern KPI both on i386 and amd64. First version of the support for AVX was submitted by Tim Bird on behalf of Sony. This version was written from scratch. Tested by: pho (previous version), Yamagi Burmeister MFC after: 1 month

Begin all license/copyright comments with /*-

2005-01-05T20:17:21Z

Remove advertising clause from University of California Regent's license,

2004-04-05T21:29:41Z

per letter dated July 22, 1999. Approved by: core

Move the definition of PT_[GS]ET{,DB,FP}REGS from the MD ptrace.h to the

2002-03-16T00:25:53Z

MI ptrace.h, since all platforms define them. Keep the MD ptrace.h around for FIX_SSTEP (which is currently only needed on Alpha).

Zap 'ptrace(PT_READ_U, ...)' and 'ptrace(PT_WRITE_U, ...)' since they

2001-08-08T05:25:15Z

are a really nasty interface that should have been killed long ago when 'ptrace(PT_[SG]ETREGS' etc came along. The entity that they operate on (struct user) will not be around much longer since it is part-per-process and part-per-thread in a post-KSE world. gdb does not actually use this except for the obscure 'info udot' command which does a hexdump of as much of the child's 'struct user' as it can get. It carries its own #defines so it doesn't break compiles.

Change #ifdef KERNEL to #ifdef _KERNEL in the public headers. "KERNEL"

1999-12-29T04:46:21Z

is an application space macro and the applications are supposed to be free to use it as they please (but cannot). This is consistant with the other BSD's who made this change quite some time ago. More commits to come.

$Id$ -> $FreeBSD$

1999-08-28T01:08:13Z

Implement support for hardware debug registers on the i386.

1999-07-09T04:16:00Z

Submitted by: Brian Dean