[Cc'ing David Matthews, upstream maintainer] On 2 Nov 2017, at 10:27, Alan Modra <amo...@gmail.com> wrote: > On Sat, 28 Oct 2017 10:51:01 -0400 John David Anglin <dave.ang...@bell.net> > wrote: >> Source: polyml >> Version: 5.7 >> Severity: normal >> >> Dear Maintainer, >> >> Build fails here: >> >> Making STRUCT_CONVERSIONALS >> Created functor STRUCT_CONVERSIONALS >> Created structure StructConversionals >> Created structure CInterface >> /bin/bash ./libtool --tag=CC --mode=link gcc -Wall -fno-strict-aliasing >> -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -Wformat >> -Werror=format-security -Wl,--as-needed -o poly polyexport.o >> libpolymain/libpolymain.la libpolyml/libpolyml.la -lpthread -lffi -lm -ldl >> -lstdc++ -lgcc_s -lgcc >> libtool: link: gcc -Wall -fno-strict-aliasing -g -O2 >> -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -Wformat -Werror=format-security >> -Wl,--as-needed -o .libs/poly polyexport.o libpolymain/.libs/libpolymain.a >> libpolyml/.libs/libpolyml.so -lpthread -lffi -lm -ldl -lstdc++ -lgcc_s -lgcc >> /usr/bin/ld: BFD (GNU Binutils for Debian) 2.29.1 internal error, aborting >> at ../../bfd/elf32-hppa.c:4054 in elf32_hppa_relocate_section >> >> /usr/bin/ld: Please report this bug. >> >> collect2: error: ld returned 1 exit status >> Makefile:588: recipe for target 'poly' failed >> >> Full build log is here: >> https://buildd.debian.org/status/fetch.php?pkg=polyml&arch=hppa&ver=5.7-2&stamp=1507223380&raw=0 >> >> The error was reported to binutils: >> https://sourceware.org/bugzilla/show_bug.cgi?id=22300 >> >> See "bug 1: polyimport, the producer of polyexport.o is using the wrong >> os/abi for hppa-linux." in comment 4. >> >> The binutils part of this bug should now be fixed by commit >> c0e331c794d6bd75d9be9bea6145513074c33f39. > > Even when this has been worked around by the binutils change, polyml > still fails to build. > > echo "use \"/home/amodra/src/polyml/modules/IntInfAsInt/ROOT.sml\";" | > ../../poly -q -error-exit > Segmentation fault > > Some debugging shows this is due to a NULL function pointer, traceable > back to this relocation in polyexport.o > > 00000134 00001301 R_PARISC_DIR32 00000000 PolyProcessEnvGeneral + 0 > > That's also an ABI violation. Function pointers on hppa32 require > plabel relocations. > > $ cat funcp.c > extern void foo(void); > void (*fp)(void) = foo; > $ hppa-linux-gcc -O -c -save-temps funcp.c > $ cat funcp.s > .LEVEL 1.1 > .globl fpr > .section .data.rel,"aw",@progbits > .align 4 > .type fp, @object > .size fp, 4 > fp: > .word P%foo > .ident "GCC: (GNU) 8.0.0 20171018 (experimental)" > .section .note.GNU-stack,"",@progbits > $ readelf -r funcp.o > > Relocation section '.rela.data.rel' at offset 0xfc contains 1 entries: > Offset Info Type Sym.Value Sym. Name + Addend > 00000000 00000841 R_PARISC_PLABEL32 00000000 foo + 0
Hi Alan, Thank you for for looking at this. Poly/ML used to only need to generate relocations for data, as compiled code never referenced functions; any RTS calls were made using a unique integer id, with a big switch statement in the runtime to dispatch. However this has been changed in the latest release to use the function names directly and these get turned into relocations for function pointers when exported to an ELF object. David, The ABI issue above should probably be fixed. If HP-UX is to be supported, we can't just use ELFOSABI_NONE instead (which binutils will accept for Linux and NetBSD), but need to choose based on whether __NetBSD__, __linux__ or __hpux is defined; that should be simple for me to write. Regarding the relocations, I believe the code now needs to have directDataReloc and directFuncReloc, rather than just directReloc, and addExternalReference can tell writeRelocation to use a function pointer relocation instead? I think IA-64 is the only other affected architecture (needing R_IA64_FPTR64LSB instead of R_IA64_DIR64LSB); ELFv1 (but not v2) PPC64 also has function descriptors, but just uses the normal R_PPC64_ADDR64 to refer to them. Regards, James
