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

2017-11-02 Thread Alan Modra
Source: polyml
Version: 5.7
Severity: normal

On Thu, Nov 02, 2017 at 08:47:30AM -0400, John David Anglin wrote:
> On 2017-11-02, at 3:59 AM, Alan Modra wrote:
> > 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
> 
> I'm not seeing this fault.  I just redid a polyml build with virgin source 
> and I didn't see the segmentation fault.
> 
> gcc version 7.2.1 20171025 (Debian 7.2.0-12) 
> 
> dave@mx3210:~/debian/polyml/polyml-5.7$ as --version
> GNU assembler (GNU Binutils) 2.29.51.20171031
> 
> Binutils was trunk with your elf32-hppa.c patch.

Yes, but that patch hasn't been committed yet.  What's more,
binutils-2.28 and binutils-2.29 both fail with a segfault (after
working around the OS/ABI problem).  I suspect older binutils will
show the same thing.

In one of my earlier emails to you Dave, I misdiagnosed the segfault
as being due to binutils commit d336fa6d82.  That wasn't true.

> > Some debugging shows this is due to a NULL function pointer, traceable
> > back to this relocation in polyexport.o
> > 
> > 0134  1301 R_PARISC_DIR32   PolyProcessEnvGeneral + 0
> > 
> > That's also an ABI violation.  Function pointers on hppa32 require
> > plabel relocations.
> 
> No, that's not correct.  Calls using function pointers are done using 
> $$dyncall or equivalent.  It checks
> the plabel bit to determine whether or not the call is direct or via an 
> function descriptor.  Direct calls
> work when a new PIC register value isn't needed.

I'll defer to you on whether it is an ABI violation.  It's been quite
a while since I've done any serious parisc work..  The fact remains
that this part of the ABI isn't currently supported by any released
binutils as far as I know.

-- 
Alan Modra
Australia Development Lab, IBM

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


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

2017-11-02 Thread Alan Modra
On Sat, 28 Oct 2017 10:51:01 -0400 John David Anglin  
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=/<>=. -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=/<>=. -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

0134  1301 R_PARISC_DIR32   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 fp
.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 InfoTypeSym.Value  Sym. Name + Addend
  0841 R_PARISC_PLABEL32    foo + 0


-- 
Alan Modra
Australia Development Lab, IBM

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers