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
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
