[Bug tdep/34434] New: [gdb/tdep] Make ppc less dependent on user area layout constants

https://sourceware.org/bugzilla/show_bug.cgi?id=34434

            Bug ID: 34434
           Summary: [gdb/tdep] Make ppc less dependent on user area layout
                    constants
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tdep
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider linux kernel commit d7a6797e0bc1 ("powerpc: add exit_flags field in
pt_regs"), available in v7.2-rc1 onwards.

The commit makes changes to the layout of the USER area, as seen by
PTRACE_POKEUSER/PTRACE_PEEKUSER.

More concretely, it changes these constants:
...
$ git show --pretty=%s d7a6797e0bc1 -- arch/powerpc/include/uapi/asm/ptrace.h |
egrep "^[+-]#define PT_"
-#define PT_DSCR 44
-#define PT_REGS_COUNT 44
+#define PT_EXIT_FLAGS 44
+#define PT_PAD 47 /* 3 times */
+#define PT_DSCR 48
+#define PT_REGS_COUNT 48
-#define PT_FPR0        48      /* each FP reg occupies 2 slots in this space
*/
+#define PT_FPR0        (PT_REGS_COUNT + 4)     /* each FP reg occupies 2 slots
in this space */
-#define PT_VR0 82      /* each Vector reg occupies 2 slots in 64-bit */
+#define PT_VR0 (PT_FPSCR + 2)  /* <82> each Vector reg occupies 2 slots in
64-bit */
-#define PT_VSR0 150    /* each VSR reg occupies 2 slots in 64-bit */
+#define PT_VSR0        (PT_VRSAVE + 2) /* each VSR reg occupies 2 slots in
64-bit */
...

Some of these constants are used in gdb, like PT_FPR0 in ppc_register_u_addr.

The way user programs (like gdb) get a constant like PT_FPR0 is as follows:
- the user program includes <sys/user.h>
- glibc's sysdeps/unix/sysv/linux/powerpc/sys/user.h includes <asm/ptrace.h>
- some package (typically linux-libc-dev or some such) provides
  /usr/include/asm/ptrace.h, which is a sanitized version of the kernel file
  arch/powerpc/include/uapi/asm/ptrace.h

When building gdb against an out-of-date /usr/include/asm/ptrace.h, PT_FPR0
will be stuck at 48, and reading/writing f1 (PT_FPR0 + 1) using
PTRACE_POKEUSER/PTRACE_PEEKUSER will get us an EIO, and reading and writing f0
will succeed, but
actually read and write DSCR. 

There are other ways to get at float point registers:
- PTRACE_GETFPREGS/SETFPREGS
- PTRACE_GETREGSET/SETREGSET

The drawback is that those are bulk methods: they always read and write the
entire register set, even if only one register is required.

We could add some probing of PTRACE_POKEUSER/PTRACE_PEEKUSER to see if it
works, and if so, use it, and otherwise fall back to bulk methods.

For the probing, I was thinking along the lines of:
- PTRACE_GETFPREGS
- PTRACE_PEEKUSER f0, and compare
- if those don't match, PTRACE_PEEKUSER can't be used for floating point regs
- the match might be accidental, so try the following
- use PTRACE_SETFPREGS to invert the bits of f0
- PTRACE_PEEKUSER f0, and compare
- if those match, we have a functional PTRACE_PEEKUSER for floating point regs
- restore f0

But perhaps the probing is overkill, I'm not sure.

-- 
You are receiving this mail because:
You are on the CC list for the bug.