[Python-Dev] Python build trouble with the new gcc/binutils

[Zack Weinberg]

--2fHTh5uZTiUOsy+g
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Aug 16, 2002 at 02:43:05PM -0400, Andrew Koenig wrote:
> Zack> Can you disable all use of dynamic loading and try the build
> Zack> again?  Unfortunately, the only practical way to do this seems
> Zack> to be to edit configure.in and force DYNLOADFILE to be
> Zack> dynload_stub.o (right before the line saying
> Zack> AC_MSG_RESULT($DYNLOADFILE)), then regenerate configure.  (Might
> Zack> be a good idea to add an --enable switch.)
> 
> As I sort of expected, this makes the crash go away.

Okay, so that pretty much guarantees it's a bug in the toolchain, or
in Solaris ld.so.

> If I put back the dynamic loading stuff and rebuild everything from scratch,
> I again get a python that crashes when I try to import struct.
> It occurs to me that the traceback from that might be useful.
> Needless to say, it is much shorter than the earlier one.
> 
> I must say that the "Address 0x2 out of bounds" note makes me suspicious.

That's almost certainly GDB screwing up.  In any case,
dynload_shlib.c's version of _PyImport_GetDynLoadFunc does not use
that argument, so that can't be the cause of the problem.

> #0  __register_frame_info_bases (begin=0xfed40000, ob=0xfed40000, tbase=0x0, 
>     dbase=0x0) at /tmp/build1165/gcc-3.1.1/gcc/unwind-dw2-fde.c:83

Having tbase and dbase be 0x0 is not a problem.  The begin and ob
pointers should _not_ be the same. ob should point to a fairly large
data object in the .bss section, and begin should point to the
beginning of the .eh_frame section.  This could be GDB screwing up
again, but unwind-dw2-fde.c is compiled with less aggressive
optimization than dynload_shlib.c, so it's more likely to be accurate.
Also, this particular screw-up is a plausible linker or dynamic linker
bug.  I suspect struct.so was loaded at address 0xfed40000, which
leaves both these pointers aimed at the beginning of the (unwritable)
.text section -- __r_f_i_b tries to modify the object pointed to by
ob, crash.

Please execute the attached shell script with CC set to your test gcc
3.2 and/or binutils 2.13.x installation and see what happens.  If we
do have a toolchain bug, it ought to be provoked by this test.

zw


--2fHTh5uZTiUOsy+g
Content-Type: application/x-sh
Content-Disposition: attachment; filename="test.sh"
Content-Transfer-Encoding: quoted-printable

#! /bin/sh=0A=0Amkdir /tmp/t.$$  || exit 3=0Acd /tmp/t.$$     || exit 3=0A=
=0Acat >main.c <<'EOF'=0A#include <stdio.h>=0A#include <dlfcn.h>=0A=0Aint m=
ain(void)=0A{=0A    void *handle, *sym;=0A    char *error;=0A=0A    puts("c=
alling dlopen");=0A    handle =3D dlopen("./dyn.so", RTLD_NOW);=0A    if (!=
handle) {=0A        printf("%s\n", dlerror());=0A	return 1;=0A    }=0A=0A  =
  puts("calling dlsym");=0A    sym =3D dlsym(handle, "sym");=0A    if ((err=
or =3D dlerror()) !=3D 0) {=0A        printf("%s\n", error);=0A	return 1;=
=0A    }=0A    puts("calling sym");=0A    ((void (*)(void))sym)();=0A    pu=
ts("done");=0A    return 0;=0A}=0AEOF=0A=0Acat >dyn.c <<'EOF'=0A#include <s=
tdio.h>=0Avoid sym(void)=0A{=0A    puts("in sym");=0A}=0AEOF=0A=0A[ -n "$SH=
FLAGS" ] || SHFLAGS=3D"-fPIC -shared"=0A[ -n "$CC" ]  || CC=3Dgcc=0A=0Aset =
-x=0A=0A$CC $CFLAGS $SHFLAGS dyn.c -o dyn.so=0A$CC $CFLAGS main.c -o main -=
ldl=0A=0A./main || exit $?=0A=0Acd /tmp=0Arm -rf t.$$=0A
--2fHTh5uZTiUOsy+g--