musl/arch/sh/bits/user.h

52 lines
1.0 KiB
C
Raw Normal View History

#undef __WORDSIZE
#define __WORDSIZE 32
#define REG_REG0 0
#define REG_REG15 15
#define REG_PC 16
#define REG_PR 17
#define REG_SR 18
#define REG_GBR 19
#define REG_MACH 20
#define REG_MACL 21
#define REG_SYSCALL 22
#define REG_FPREG0 23
#define REG_FPREG15 38
#define REG_XFREG0 39
#define REG_XFREG15 54
#define REG_FPSCR 55
#define REG_FPUL 56
struct user_fpu_struct {
unsigned long fp_regs[16];
unsigned long xfp_regs[16];
unsigned long fpscr;
unsigned long fpul;
};
#define ELF_NGREG 23
typedef unsigned long elf_greg_t;
typedef elf_greg_t elf_gregset_t[ELF_NGREG];
typedef struct user_fpu_struct elf_fpregset_t;
struct user {
fix clash between sys/user.h and kernel ptrace.h on powerpc[64], sh due to historical accident/sloppiness in glibc, the powerpc, powerpc64, and sh versions of struct user, defined by sys/user.h, used struct pt_regs from the kernel asm/ptrace.h for their regs member. this made it impossible to define the type in an API-compatible manner without either including asm/ptrace.h like glibc does (contrary to our policy of not depending on kernel headers), or clashing with asm/ptrace.h's definition of struct pt_regs if both headers are included (which is almost always the case in software using sys/user.h). for a long time I viewed this problem as having no reasonable fix. I even explored the possibility of having the powerpc[64] and sh versions of user.h just include the kernel header (breaking with policy), but that looked like it might introduce new clashes with sys/ptrace.h. and it would also bring in a lot of additional cruft that makes no sense for sys/user.h to expose. glibc goes out of its way to suppress some of that with #undef, possibly leading to different problems. this is a rabbit-hole that should be explored no further. as it turns out, however, nothing actually uses struct user sufficiently to care about the type of the regs member; most software including sys/user.h does not even use struct user at all. so, the problem can be fixed just by doing away with the insistence on strict glibc API compatibility for the struct tag of the regs member. rather than renaming the tag, which might lead to the new name entering use as API, simply use an untagged structure inside struct user with the same members/layout as struct pt_regs. for sh, struct pt_dspregs is just removed entirely since it was not used.
2019-08-19 03:41:17 +00:00
struct {
unsigned long regs[16];
unsigned long pc, pr, sr, gbr, mach, macl;
long tra;
} regs;
struct user_fpu_struct fpu;
int u_fpvalid;
unsigned long u_tsize;
unsigned long u_dsize;
unsigned long u_ssize;
unsigned long start_code;
unsigned long start_data;
unsigned long start_stack;
long int signal;
unsigned long u_ar0;
struct user_fpu_struct *u_fpstate;
unsigned long magic;
char u_comm[32];
};