On Mon, Oct 19, 2020, at 3:15 AM, David Matthews wrote: > 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
AFAIK, strictly speaking, executability is not relevant here. The Linux manpage documents DT_TEXTREL as "Absence of this entry indicates that no relocation entries should apply to a nonwritable segment" and musl is crashing because it maps the text segment with r-x permissions, and then attempts to write to it while processing relocations. A related issue is that musl only implements the relocation types that are useful in data sections, i.e. "write absolute address to a word-sized adequately aligned field". > 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 Yes, in C you can initialize a global variable with a pointer to another global variable. > 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. I think you should still be able to use PC-relative addressing there, as long as the relocations can be completely resolved at the initial link time. Supporting PIE on 32-bit x86 would be harder. Would it be reasonable to have a configure test which automatically sets -no-pie if the linker supports it, and/or if a test program with a text relocation cannot be run? > 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@inf.ed.ac.uk > > http://lists.inf.ed.ac.uk/mailman/listinfo/polyml > > > _______________________________________________ > polyml mailing list > polyml@inf.ed.ac.uk > http://lists.inf.ed.ac.uk/mailman/listinfo/polyml > _______________________________________________ polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
