Bug#880023: polyml: FTBFS on hppa - error linking poly

[James Clarke]

[Cc'ing David Matthews, upstream maintainer]

On 2 Nov 2017, at 10:27, Alan Modra <amodra at gmail.com> wrote:
> On Sat, 28 Oct 2017 10:51:01 -0400 John David Anglin <dave.anglin at 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", at 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,"", at 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