IY84249: SEGMENTATION FAULT IN 32-BIT MODE

April 2006 XL C/C++ Enterprise Edition V7.0 for AIX PTF
April 2006 XL C Enterprise Edition V7.0 for AIX PTF
Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The test case fails with a segmentation fault when compiled with
  XL C V7. Specifically the failure occurs only when the file
  "t1.c" is compiled with XL C V7.
  
  The test case works fine when compiled with GCC.
  
  The makefile creates four GCC-XLC combinations of the final
  executable. Only those instances where "t1.c" was compiled with
  XL C V7 fail: xx-test and xg-test.
  
  This happens only in 32-bit mode.
  
  An unrelated linker bug may prevent prevent this from being
  recreated on SLES9. The symtom is that all four executables die
  with SIGILL. According to the vendor this bug is fixed in
  SLES10.
  
  
  
  TESTCASE:
  /*** t1.c ***/
  #include <stdio.h>
  
  typedef unsigned int ub4;
  typedef unsigned char ub1;
  typedef char oratext;
  
  #define GENEZI_PATTERN
  {0x00010203,0x04050607,0x08090a0b,0x0c0d0e0f}
  #define GENEZI_PATLEN  16
  #define OCIEI_ARRSIZE    17524265 /* totalBytes = 91361749 */
  static ub4 ocieiFileBuffer[OCIEI_ARRSIZE] = GENEZI_PATTERN;
  
  static ub1 *ocieiSrcOff = (oratext *)(ocieiFileBuffer) +
  GENEZI_PATLEN;
  
  void foo(){
     printf("ocieiFileBuffer = %p\n", ocieiFileBuffer);
     printf("ocieiSrcOff should be %p\n", (oratext
             *)(ocieiFileBuffer) + GENEZI_PATLEN);
     printf("ocieiSrcOff is %p \n" , ocieiSrcOff);
     *ocieiSrcOff = (char)10;
  }
  
  
  
  /*** t2.c ***/
  #include <dlfcn.h>
  #include <sys/errno.h>
  
  typedef unsigned int ub4;
  typedef unsigned char ub1;
  typedef char oratext;
  
  int main(){
     foo();
  }
  
  
  
  ### Makefile ###
  XLC=/.../torolab.ibm.com/fs/projects/vabld/run/vacpp/70/sles_ppc
  /daily/latest/bin/xlc -q32 -qpic=large
  GCC=gcc -m32 -fPIC
  LINKSHARED=gcc -m32 -shared -fPIC -Wl,-relax
  LINK=gcc -m32 -Wl,-rpath=. -fPIC
  
  all: xx-test gg-test xg-test gx-test g-t1.s x-t1.s
  
  g-t1.s: t1.c
         $(GCC) -S t1.c -o g-t1.s
  
  x-t1.s: t1.c
         $(XLC) -S t1.c -o x-t1.s
  
  xx-test: x-t1.o x-t2.o libxt1.so
         $(LINK) x-t2.o -L. -lxt1 -o xx-test
  
  libxt1.so: x-t1.o
         $(LINKSHARED) x-t1.o -o libxt1.so
  
  libgt1.so: g-t1.o
         $(LINKSHARED) g-t1.o -o libgt1.so
  
  gg-test: g-t1.o g-t2.o libgt1.so
         $(LINK) g-t2.o -L. -lgt1 -o gg-test
  
  xg-test: x-t1.o g-t2.o libxt1.so
         $(LINK) g-t2.o -L. -lxt1 -o xg-test
  
  gx-test: g-t1.o x-t2.o libgt1.so
         $(LINK) x-t2.o -L. -lgt1 -o gx-test
  
  x-t1.o: t1.c
         $(XLC) -c t1.c -o x-t1.o
  
  x-t2.o: t2.c
         $(XLC) -c t2.c -o x-t2.o
  
  g-t1.o: t1.c
         $(GCC) -c t1.c -o g-t1.o
  
  g-t2.o: t2.c
         $(GCC) -c t2.c -o g-t2.o
  
  clean:
         rm -f *.o *.so xx-test gg-test xg-test gx-test x-t1.s
  g-t1.s
  

Local fix

• Use 64-bit mode if possible.
  

Problem summary

• Interraction between -qpic and large data (> 16M) forces the
  need for -relax. The problem is that -relax will introduce
  'trampolines' to get to destinations that are > 16M away.
  Unfortunately, the pic code to establish addressibility
  hasn't saved gpr0 (the link register contents) at the point
  where the trampoline clobbers gpr0.
  

Problem conclusion

• The problem has been corrected by ensuring that gpr0 is saved
  before calling _GLOBAL_OFFSET_TABLE to setup the table.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

  LI71208

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  XLC AIX

• Fixed component ID

  5724I1000

Applicable component levels

• R700 PSY U812645

     07/08/02 I 1000

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.