xref: /openbmc/linux/arch/x86/include/asm/user_64.h (revision 0c9dceb9)
1b2441318SGreg Kroah-Hartman /* SPDX-License-Identifier: GPL-2.0 */
21965aae3SH. Peter Anvin #ifndef _ASM_X86_USER_64_H
31965aae3SH. Peter Anvin #define _ASM_X86_USER_64_H
4bb898558SAl Viro 
5bb898558SAl Viro #include <asm/types.h>
6bb898558SAl Viro #include <asm/page.h>
7bb898558SAl Viro /* Core file format: The core file is written in such a way that gdb
8bb898558SAl Viro    can understand it and provide useful information to the user.
9bb898558SAl Viro    There are quite a number of obstacles to being able to view the
10bb898558SAl Viro    contents of the floating point registers, and until these are
11bb898558SAl Viro    solved you will not be able to view the contents of them.
12bb898558SAl Viro    Actually, you can read in the core file and look at the contents of
13bb898558SAl Viro    the user struct to find out what the floating point registers
14bb898558SAl Viro    contain.
15bb898558SAl Viro 
16bb898558SAl Viro    The actual file contents are as follows:
17bb898558SAl Viro    UPAGE: 1 page consisting of a user struct that tells gdb what is present
18bb898558SAl Viro    in the file.  Directly after this is a copy of the task_struct, which
19bb898558SAl Viro    is currently not used by gdb, but it may come in useful at some point.
20bb898558SAl Viro    All of the registers are stored as part of the upage.  The upage should
21bb898558SAl Viro    always be only one page.
22bb898558SAl Viro    DATA: The data area is stored.  We use current->end_text to
23bb898558SAl Viro    current->brk to pick up all of the user variables, plus any memory
24bb898558SAl Viro    that may have been malloced.  No attempt is made to determine if a page
25bb898558SAl Viro    is demand-zero or if a page is totally unused, we just cover the entire
26bb898558SAl Viro    range.  All of the addresses are rounded in such a way that an integral
27bb898558SAl Viro    number of pages is written.
28bb898558SAl Viro    STACK: We need the stack information in order to get a meaningful
29bb898558SAl Viro    backtrace.  We need to write the data from (esp) to
30bb898558SAl Viro    current->start_stack, so we round each of these off in order to be able
31bb898558SAl Viro    to write an integer number of pages.
32bb898558SAl Viro    The minimum core file size is 3 pages, or 12288 bytes.  */
33bb898558SAl Viro 
34bb898558SAl Viro /*
35bb898558SAl Viro  * Pentium III FXSR, SSE support
36bb898558SAl Viro  *	Gareth Hughes <gareth@valinux.com>, May 2000
37bb898558SAl Viro  *
38bb898558SAl Viro  * Provide support for the GDB 5.0+ PTRACE_{GET|SET}FPXREGS requests for
39bb898558SAl Viro  * interacting with the FXSR-format floating point environment.  Floating
40bb898558SAl Viro  * point data can be accessed in the regular format in the usual manner,
41bb898558SAl Viro  * and both the standard and SIMD floating point data can be accessed via
42bb898558SAl Viro  * the new ptrace requests.  In either case, changes to the FPU environment
43bb898558SAl Viro  * will be reflected in the task's state as expected.
44bb898558SAl Viro  *
45bb898558SAl Viro  * x86-64 support by Andi Kleen.
46bb898558SAl Viro  */
47bb898558SAl Viro 
48bb898558SAl Viro /* This matches the 64bit FXSAVE format as defined by AMD. It is the same
49bb898558SAl Viro    as the 32bit format defined by Intel, except that the selector:offset pairs
50bb898558SAl Viro    for data and eip are replaced with flat 64bit pointers. */
51bb898558SAl Viro struct user_i387_struct {
52bb898558SAl Viro 	unsigned short	cwd;
53bb898558SAl Viro 	unsigned short	swd;
54bb898558SAl Viro 	unsigned short	twd;	/* Note this is not the same as
55bb898558SAl Viro 				   the 32bit/x87/FSAVE twd */
56bb898558SAl Viro 	unsigned short	fop;
57bb898558SAl Viro 	__u64	rip;
58bb898558SAl Viro 	__u64	rdp;
59bb898558SAl Viro 	__u32	mxcsr;
60bb898558SAl Viro 	__u32	mxcsr_mask;
61bb898558SAl Viro 	__u32	st_space[32];	/* 8*16 bytes for each FP-reg = 128 bytes */
62bb898558SAl Viro 	__u32	xmm_space[64];	/* 16*16 bytes for each XMM-reg = 256 bytes */
63bb898558SAl Viro 	__u32	padding[24];
64bb898558SAl Viro };
65bb898558SAl Viro 
66bb898558SAl Viro /*
67bb898558SAl Viro  * Segment register layout in coredumps.
68bb898558SAl Viro  */
69bb898558SAl Viro struct user_regs_struct {
70bb898558SAl Viro 	unsigned long	r15;
71bb898558SAl Viro 	unsigned long	r14;
72bb898558SAl Viro 	unsigned long	r13;
73bb898558SAl Viro 	unsigned long	r12;
74bb898558SAl Viro 	unsigned long	bp;
75bb898558SAl Viro 	unsigned long	bx;
76bb898558SAl Viro 	unsigned long	r11;
77bb898558SAl Viro 	unsigned long	r10;
78bb898558SAl Viro 	unsigned long	r9;
79bb898558SAl Viro 	unsigned long	r8;
80bb898558SAl Viro 	unsigned long	ax;
81bb898558SAl Viro 	unsigned long	cx;
82bb898558SAl Viro 	unsigned long	dx;
83bb898558SAl Viro 	unsigned long	si;
84bb898558SAl Viro 	unsigned long	di;
85bb898558SAl Viro 	unsigned long	orig_ax;
86bb898558SAl Viro 	unsigned long	ip;
87bb898558SAl Viro 	unsigned long	cs;
88bb898558SAl Viro 	unsigned long	flags;
89bb898558SAl Viro 	unsigned long	sp;
90bb898558SAl Viro 	unsigned long	ss;
91bb898558SAl Viro 	unsigned long	fs_base;
92bb898558SAl Viro 	unsigned long	gs_base;
93bb898558SAl Viro 	unsigned long	ds;
94bb898558SAl Viro 	unsigned long	es;
95bb898558SAl Viro 	unsigned long	fs;
96bb898558SAl Viro 	unsigned long	gs;
97bb898558SAl Viro };
98bb898558SAl Viro 
99bb898558SAl Viro /* When the kernel dumps core, it starts by dumping the user struct -
100bb898558SAl Viro    this will be used by gdb to figure out where the data and stack segments
101bb898558SAl Viro    are within the file, and what virtual addresses to use. */
102bb898558SAl Viro 
103bb898558SAl Viro struct user {
104bb898558SAl Viro /* We start with the registers, to mimic the way that "memory" is returned
105bb898558SAl Viro    from the ptrace(3,...) function.  */
106bb898558SAl Viro   struct user_regs_struct regs;	/* Where the registers are actually stored */
107bb898558SAl Viro /* ptrace does not yet supply these.  Someday.... */
108bb898558SAl Viro   int u_fpvalid;		/* True if math co-processor being used. */
109bb898558SAl Viro 				/* for this mess. Not yet used. */
110bb898558SAl Viro   int pad0;
111bb898558SAl Viro   struct user_i387_struct i387;	/* Math Co-processor registers. */
112bb898558SAl Viro /* The rest of this junk is to help gdb figure out what goes where */
113bb898558SAl Viro   unsigned long int u_tsize;	/* Text segment size (pages). */
114bb898558SAl Viro   unsigned long int u_dsize;	/* Data segment size (pages). */
115bb898558SAl Viro   unsigned long int u_ssize;	/* Stack segment size (pages). */
116bb898558SAl Viro   unsigned long start_code;     /* Starting virtual address of text. */
117bb898558SAl Viro   unsigned long start_stack;	/* Starting virtual address of stack area.
118bb898558SAl Viro 				   This is actually the bottom of the stack,
119bb898558SAl Viro 				   the top of the stack is always found in the
120bb898558SAl Viro 				   esp register.  */
121bb898558SAl Viro   long int signal;		/* Signal that caused the core dump. */
122bb898558SAl Viro   int reserved;			/* No longer used */
123bb898558SAl Viro   int pad1;
124bb898558SAl Viro   unsigned long u_ar0;		/* Used by gdb to help find the values for */
125bb898558SAl Viro 				/* the registers. */
126bb898558SAl Viro   struct user_i387_struct *u_fpstate;	/* Math Co-processor pointer. */
127bb898558SAl Viro   unsigned long magic;		/* To uniquely identify a core file */
128bb898558SAl Viro   char u_comm[32];		/* User command that was responsible */
129bb898558SAl Viro   unsigned long u_debugreg[8];
130bb898558SAl Viro   unsigned long error_code; /* CPU error code or 0 */
131bb898558SAl Viro   unsigned long fault_address; /* CR3 or 0 */
132bb898558SAl Viro };
133bb898558SAl Viro 
1341965aae3SH. Peter Anvin #endif /* _ASM_X86_USER_64_H */
135