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

[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 at 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
> > 
> > 00000134  00001301 R_PARISC_DIR32    00000000   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