Hi, I'm pleased you've found a fix for this. A while ago I looked into how to get Poly/ML to install on hardened systems such as SELinux and OpenBSD and fixed a problem with dynamically created code which generally requires an area of memory to be both executable and writeable. Textrels were still a problem and required a linker option. See http://lists.inf.ed.ac.uk/pipermail/polyml/2020-August/002370.html .
As I understand it, a TEXTREL is where the TEXT, executable, read-only code contains an absolute address. When Poly/ML compiles a function the code object it creates consists of the machine code followed by a section of constants, often addresses. Even if the function itself does not use an address there is always a pointer to the name of the function as a string and to a ref that can be used for profiling. I would guess that it is these that result in the TEXTRELs.
I would assume that it is still possible to have absolute addresses in an executable but that these are supposed to be in a data section rather than in the text section. Is that the case? It is certainly not possible to create an ML object file without any absolute addresses since the object file could contain structures such as lists. If the section of constants for a function were pulled out so that they were written into a data section would that solve the problem? Currently, at least on the X86-64, the code itself uses PC-relative addressing to access the constant area. The offsets are currently frozen when the code is built since the constant area does not move relative to code but that would change if the constants were part of a different object file section.
Regards, David
On 18/10/2020 00:25, Stefan O'Rear wrote:
On Sat, Oct 17, 2020, at 6:29 PM, David Topham wrote:
I noticed same error seemed to have occurred from user installing to gentoo Linux. I can't tell from this if it was resolved or not (I'm relatively inexperienced)
https://bugs.gentoo.org/713178
One thing in common between Alpine and this environment is they are using musl libc
Could that be an issue?
I built polyml HEAD in an alpine chroot and reproduced the crash.
e6081b5540fb:~/polyml$ readelf -d .libs/lt-poly | grep TEXTREL 0x0000000000000016 (TEXTREL) 0x0
TEXTREL is not supported by musl, so this is the problem. This indicates that position-dependent code has somehow gotten into an executable marked as PIE.
If I configure poly/ml using:
./configure LDFLAGS="-no-pie"it works.
Nothing is installed here except musl-dev gcc g++ make git curl; it is a fresh git checkout, rev d68c673.
Looking at polyexport.o (with objdump -d -r) there are a large number of X86_64_RELATIVE relocations in area%1u symbols, mixed with data that visually looks like x86_64 machine code. The relocations apply to aligned 64-bit blocks, not 64-bit immediates in move instructions. Not sure if this is easily fixable or if poly does something like old GHC that relies on mixing data and code so closely.
-s _______________________________________________ polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml