Cary has accepted this value on https://groups.google.com/g/generic-abi/c/satyPkuMisk/m/KwTF_U8rBAAJ

Thanks! I don't want llvm-project to be blocked by the generic-ABI's keeping postponing, too. I guess if FreeBSD decides to define this, llvm-project can move on, too.

You may cherry pick https://github.com/llvm/llvm-project/commit/53fc5d9b9a0110f097c6e9f7aa3bff3621eaf268 to avoid the local changes.

In D34215#774206, @emaste wrote:

Double-checking, Fangrui Song <i@maskray.me> is the correct author info?

remove -dc from comment

Fix comment

Needs to fix a comment.

Folks may be interested in

git format-patch -2 --stdout of D32526 + D32524: https://gist.github.com/MaskRay/4df58dc970a377d04ec93a983685f1d4

address style issues

ld.lld's RELR is robust since 2019-04 (https://reviews.llvm.org/D67164) when I fixed an oscillation bug.

address comments

const char* -> const char *

RELR is like a modern version of Firefox’s ELF hack https://glandium.org/blog/?p=1177#relocations

This is not suitable for the upstream. The root cause behind dso_local needs to be found and fixed.

In D31498#711395, @arichardson wrote:

In D31498#710007, @fbsd-phab_maskray.me wrote:

(FreeBSD on non-FreeBSD isn't smooth. i cannot do a build test.)

@fbsd-phab_maskray.me Could you post the error message somewhere? In general, cross-builds from linux+macOS should work, and I try to fix them after any breaking change.

Thanks:)

D31538 is a functional change. I think it'd be good not to fix functional change without unrelated cleanups.

fix the condition

actually default to true

FWIW TLS_BELOW_TP and TLS_ABOVE_TP are more descriptive. VARIANT_I and VARIANT_II are less clear. In addition, technically arm/aarch64 are not strict Variant I because of the 2 reserved words. mips/powerpc are not strict Variant I because of a non-zero DTP offset. FreeBSD doesn't support the strict Variant I architectures (e.g. Alpha, ia64)

In D26352#711126, @kib wrote:

Dynamic linker itself is just an example of the breakage. There are more problems with e.g. libc/libthr, and this is only the base system. I do not know how much and where other problems are, in real world.

More, what users would do with this env var? They see that an app does not work, so what is next? How could they know that the env var needs to be set and _this_ is the cause of the breakage. And note that the variable must be ignored for setuid/setgid images.

So it cannot be handled this way.

I think your patch might be useful for experimentation, if you flip the meaning of the env var. That is, instead of making default standard-compliant, keep it as is. If the var is set, switch to desired behavior. Then we can commit this and some users would help us with evaluating the scope of the problem. In fact, I think this is a good first step.

Disable by default

Simplify allocate_tls

add doc

You may use git commit --amend --author='Fangrui Song <i@maskray.me>'

In D31498#710053, @kib wrote:

I do not understand this patch.

If linker specified that the end of relro is in the middle of some page, this means that there are relocations targeting that page. If we truncate relro_size, then relocation processing would operate on ro mapping and get SIGBUS/SIGSEGV.

(FreeBSD on non-FreeBSD isn't smooth. i cannot do a build test.)

I want to read some rtld-elf and libc code on Linux. I cannot run buildworld but want to generate a compile_commands.json to make my ccls happy. What should I do?

In D23652#708723, @kib wrote:

In D23652#708577, @fbsd-phab_maskray.me wrote:

Where do you think R_*_IRELATIVE should reside in? .rela.dyn or .rela.plt?

GNU ld's x86 port picks .rela.plt for https://sourceware.org/bugzilla/show_bug.cgi?id=13302
which may be related to this sentence "This may work on x86_64 where the R_*_IRELATIVE relocations happen in DT_JMPREL after the DT_REL* relocations, but that is no guarantee that it will work on AArch64, PPC64, or other architectures that are slightly different" on https://sourceware.org/glibc/wiki/GNU_IFUNC

For us it should not make a difference. We process whole DT_RELA while looking for IRELATIVE.

Where do you think R_*_IRELATIVE should reside in? .rela.dyn or .rela.plt?

Fix all STB_WEAK occurrences

In D26352#585872, @kib wrote:

This breaks FreeBSD. If you look at the deleted block, the deleted comment explains why (and this is only one instance of it, there are more).

This has been supported since GCC 6/clang 9 (https://reviews.llvm.org/D57394). It would be better if the logic were conditioned on __GCC_ASM_FLAG_OUTPUTS__.

I am hoping an administrator can change my username to something else. I don't want to expose my email address this way.

I really hope some administrator can change my username to something more sensible.

Looks good.

In D21163#465743, @kib wrote:

In D21163#464395, @i_maskray.me wrote:

...
Experiment with a few different alignments

Is that what you mean ?

diff --git a/lld/ELF/Writer.cpp b/lld/ELF/Writer.cpp
index 9db4259be49..b8b154d1f32 100644
--- a/lld/ELF/Writer.cpp
+++ b/lld/ELF/Writer.cpp
@@ -2236,12 +2236,14 @@ template <class ELFT> void Writer<ELFT>::fixSectionAlignments() {
       // p_align for dynamic TLS blocks (PR/24606), FreeBSD rtld has the same
       // bug, musl (TLS Variant 1 architectures) before 1.1.23 handled TLS
       // blocks correctly. We need to keep the workaround for a while.
+#if 0
       else if (Out::tlsPhdr && Out::tlsPhdr->firstSec == p->firstSec)
         cmd->addrExpr = [] {
           return alignTo(script->getDot(), config->maxPageSize) +
                  alignTo(script->getDot() % config->maxPageSize,
                          Out::tlsPhdr->p_align);
         };
+#endif
       else
         cmd->addrExpr = [] {
           return alignTo(script->getDot(), config->maxPageSize) +

?

In D21476#469183, @jhibbits wrote:

Can you instead add something like the following to crt1.c?

#if !defined(GCRT) && !defined(PIC)
__asm__(".text\n"
             "\t.global _GLOBAL_OFFSET_TABLE\n"
            "\t.reloc 0, R_PPC_NONE, _GLOBAL_OFFSET_TABLE_");
#endif

Local-Exec TP offsets are link-time constants, and thus contracts between ld and ld.so. It may be worth checking if rtld-elf computed Local-Exec TP offsets match lld.