src/sys/amd64/include/sigframe.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)

Convert machine/elf.h, machine/frame.h, machine/sigframe.h,

2013-02-20T17:39:52Z

machine/signal.h and machine/ucontext.h into common x86 includes, copying from amd64 and merging with i386. Kernel-only compat definitions are kept in the i386/include/sigframe.h and i386/include/signal.h, to reduce amd64 kernel namespace pollution. The amd64 compat uses its own definitions so far. The _MACHINE_ELF_WANT_32BIT definition is to allow the sys/boot/userboot/userboot/elf32_freebsd.c to use i386 ELF definitions on the amd64 compile host. The same hack could be usefully abused by other code too.

Commit MD parts of a loosely functional AMD64 port. This is based on

2003-05-01T01:05:25Z

a heavily stripped down FreeBSD/i386 (brutally stripped down actually) to attempt to get a stable base to start from. There is a lot missing still. Worth noting: - The kernel runs at 1GB in order to cheat with the pmap code. pmap uses a variation of the PAE code in order to avoid having to worry about 4 levels of page tables yet. - It boots in 64 bit "long mode" with a tiny trampoline embedded in the i386 loader. This simplifies locore.s greatly. - There are still quite a few fragments of i386-specific code that have not been translated yet, and some that I cheated and wrote dumb C versions of (bcopy etc). - It has both int 0x80 for syscalls (but using registers for argument passing, as is native on the amd64 ABI), and the 'syscall' instruction for syscalls. int 0x80 preserves all registers, 'syscall' does not. - I have tried to minimize looking at the NetBSD code, except in a couple of places (eg: to find which register they use to replace the trashed %rcx register in the syscall instruction). As a result, there is not a lot of similarity. I did look at NetBSD a few times while debugging to get some ideas about what I might have done wrong in my first attempt.

Split 4.x and 5.x signal handling so that we can keep 4.x signal

2002-10-25T19:10:58Z

handling clean and functional as 5.x evolves. This allows some of the nasty bandaids in the 5.x codepaths to be unwound. Encapsulate 4.x signal handling under COMPAT_FREEBSD4 (there is an anti-foot-shooting measure in place, 5.x folks need this for a while) and finish encapsulating the older stuff under COMPAT_43. Since the ancient stuff is required on alpha (longjmp(3) passes a 'struct osigcontext *' to the current sigreturn(2), instead of the 'ucontext_t *' that sigreturn is supposed to take), add a compile time check to prevent foot shooting there too. Add uniform COMPAT_43 stubs for ia64/sparc64/powerpc. Tested on: i386, alpha, ia64. Compiled on sparc64 (a few days ago). Approved by: re

Use struct __ucontext in prototypes and associated functions instead of

2002-02-17T17:40:34Z

ucontext_t. Forward declare struct __ucontext in and remove reliance on being included. While I'm here, also hide osigcontext types from userland; suggested by bde. Namespace pollution noticed by: Kevin Day

style(9) the structure definitions.

2001-09-05T01:36:46Z

Fix type of sf_addr.

1999-12-04T10:40:24Z

Pointed out by: bde

Change the type of sf_addr in struct {o}sigframe from char* to

1999-11-12T11:21:34Z

register_t. Fix some style bugs and bitrotted comments. Submitted by: bde

Simplification of the signal trampoline and other cleanups.

1999-10-07T12:40:34Z

o Remove unused defines from genassym.c that were needed by the trampoline. o Add load_gs_param function to support.s that catches a fault when %gs is loaded with an invalid descriptor. The function returns EFAULT in that case. o Remove struct trapframe from mcontext_t and replace it with the list of registers. o Modify sendsig and sigreturn accordingly. This commit contains a patch by bde. Reviewed by: luoqi, jdp

Fix style bugs caused by using the wrong file to copy from. That one

1999-10-03T12:55:58Z

gets fixed later on. Reinstate the mysterious 4th argument to signal handlers and add some comments on that.