Re: step-into-handler.c compilation failure on ppc64

[Jan Kratochvil]

On Sat, 05 Dec 2009 18:19:20 +0100, Roland McGrath wrote:
 How about this?
 
 --- step-into-handler.c   10 Dec 2008 04:42:43 -0800  1.8
 +++ step-into-handler.c   05 Dec 2009 09:18:54 -0800  
[...]
 @@ -113,11 +114,11 @@ handler_alrm_get (void)
  {
  #if defined __powerpc64__
/* ppc64 `handler_alrm' resolves to the function descriptor.  */
 -  return *(void **) handler_alrm;
 +  return *(void **) (uintptr_t) handler_alrm;
  /* __s390x__ defines both the symbols.  */
  #elif defined __s390__  !defined __s390x__
/* s390 bit 31 is zero here but I am not sure if it cannot be arbitrary.  
 */
[...]

On Sat, 05 Dec 2009 18:39:05 +0100, CAI Qian wrote:
 Thanks. Fixed.

I have to say it did not help for me (gcc-4.4.2-7.el6.ppc64).
error: dereferencing type-punned pointer will break strict-aliasing 
rules

Checked-in the union-based fix below (both tests PASS on ppc64).


Regards,
Jan

--- erestartsys.c   27 Nov 2009 22:50:31 -  1.13
+++ erestartsys.c   14 Dec 2009 00:38:42 -  1.14
@@ -38,6 +38,7 @@
 #include stddef.h
 #include pty.h
 #include string.h
+#include stdint.h
 
 #if defined __x86_64__
 # define REGISTER_IP .rip
@@ -298,8 +299,23 @@ main (int argc, char **argv)
   user = user_orig;
   user REGISTER_IP = (unsigned long) func;
 #ifdef __powerpc64__
-  user.nip = ((const unsigned long *) func)[0]; /* entry */
-  user.gpr[2] = ((const unsigned long *) func)[1]; /* TOC */
+  {
+/* ppc64 `func' resolves to the function descriptor.  */
+union
+  {
+   void (*f) (void);
+   struct
+ {
+   void *entry;
+   void *toc;
+ }
+   *p;
+  }
+const func_u = { func };
+
+user.nip = (uintptr_t) func_u.p-entry;
+user.gpr[2] = (uintptr_t) func_u.p-toc;
+  }
 #endif
   /* GDB amd64_linux_write_pc():  */
   /* We must be careful with modifying the program counter.  If we
--- step-into-handler.c 8 Dec 2008 18:23:41 -   1.8
+++ step-into-handler.c 14 Dec 2009 00:38:42 -  1.9
@@ -113,7 +113,19 @@ handler_alrm_get (void)
 {
 #if defined __powerpc64__
   /* ppc64 `handler_alrm' resolves to the function descriptor.  */
-  return *(void **) handler_alrm;
+  union
+{
+  void (*f) (int signo);
+  struct
+   {
+ void *entry;
+ void *toc;
+   }
+  *p;
+}
+  const func_u = { handler_alrm };
+
+  return func_u.p-entry;
 /* __s390x__ defines both the symbols.  */
 #elif defined __s390__  !defined __s390x__
   /* s390 bit 31 is zero here but I am not sure if it cannot be arbitrary.  */

step-into-handler.c compilation failure on ppc64

[caiqian]

# make check
...
gcc -DPACKAGE_NAME=\ptrace\ regression\ test\ suite\ 
-DPACKAGE_TARNAME=\ptrace-tests\ -DPACKAGE_VERSION=\0.1\ 
-DPACKAGE_STRING=\ptrace\ regression\ test\ suite\ 0.1\ 
-DPACKAGE_BUGREPORT=\utrace-de...@redhat.com\ -DPACKAGE=\ptrace-tests\ 
-DVERSION=\0.1\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 
-I.-std=gnu99 -Wall -Werror -g -O2 -MT step-into-handler.o -MD -MP -MF 
.deps/step-into-handler.Tpo -c -o step-into-handler.o step-into-handler.c
cc1: warnings being treated as errors
step-into-handler.c: In function ‘handler_alrm_get’:
step-into-handler.c:116: error: dereferencing type-punned pointer will break 
strict-aliasing rules
make[1]: *** [step-into-handler.o] Error 1
make[1]: Leaving directory 
`/mnt/tests/kernel/misc/ptrace-testsuite/ptrace-tests/tests'
make: *** [check] Error 2

There could be a better fix. This patch only add -fno-strict-aliasing to ignore 
the warning.--- tests/Makefile.in.orig	2009-12-05 12:07:27.726259155 -0500
+++ tests/Makefile.in	2009-12-05 12:07:47.107196650 -0500
@@ -547,7 +547,7 @@
 	   user-area-padding			\
 	   reparent-zombie-clone
 
-AM_CFLAGS = -std=gnu99 -Wall -Werror
+AM_CFLAGS = -std=gnu99 -Wall -Werror -fno-strict-aliasing
 x86_64_ia32_gs_LDFLAGS = -lpthread
 late_ptrace_may_attach_check_LDFLAGS = -lpthread
 ppc_dabr_race_LDFLAGS = -lpthread

Re: step-into-handler.c compilation failure on ppc64

[Roland McGrath]

How about this?

--- step-into-handler.c 10 Dec 2008 04:42:43 -0800  1.8
+++ step-into-handler.c 05 Dec 2009 09:18:54 -0800  
@@ -35,6 +35,7 @@
 #include sys/time.h
 #include string.h
 #include stddef.h
+#include stdint.h
 
 #if defined __x86_64__
 #define REGISTER_IP regs.rip
@@ -113,11 +114,11 @@ handler_alrm_get (void)
 {
 #if defined __powerpc64__
   /* ppc64 `handler_alrm' resolves to the function descriptor.  */
-  return *(void **) handler_alrm;
+  return *(void **) (uintptr_t) handler_alrm;
 /* __s390x__ defines both the symbols.  */
 #elif defined __s390__  !defined __s390x__
   /* s390 bit 31 is zero here but I am not sure if it cannot be arbitrary.  */
-  return (void *) (0x7fff  (unsigned long) handler_alrm);
+  return (void *) (0x7fff  (uintptr_t) handler_alrm);
 #else
   return handler_alrm;
 #endif

Re: step-into-handler.c compilation failure on ppc64

[CAI Qian]

 How about this?

Thanks. Fixed.