In rL325887#291580, @grimar wrote:

I think that the inconsistency of linkers behavior shown above shows that LLD behavior is
not incorrect. It is different. But we never tried to be fully bug compatible with bfd/gold.
First of all the problem is caused by a weak assumption in the linker script, which assumes
that orphans are placed at the particular place before the assignment command,
and my feeling it should be fixed.

Here is the shortest test case I could come up with. (This uses ld.lld-r325886, but it could also use ld.lld 6.0.1.)

In rL325887#291458, @grimar wrote:

I am still debugging it, but one observation to mention:

If you remove the .data1 : { *(.data1) } line from the script,
(https://github.com/freebsd/freebsd/blob/master/sys/conf/ldscript.i386#L141)
you'll get the same result as after this patch

.data1 is the empty section and it is anyways removed. But with this patch, it is done a bit earlier, what does not
allows our orphan placement algorithm to see/use it for finding the insertion point.

So it is just a luck that the script worked before this revision.

In rL325887#290552, @grimar wrote:

My guess it happens because of set_sysinit_set, set_sysuninit_set, set_pcpu, set_vnet are orphans (not listed in the linker script),
and our algorithm of placing the orphans started to place them in between of
(https://github.com/freebsd/freebsd/blob/master/sys/conf/ldscript.i386#L142)

_edata = .; PROVIDE (edata = .);
__bss_start = .;

for some reason. And honestly, I would not call this incorrect behavior, though I do not understand now how this patch could affect this.

In rL325887#290840, @grimar wrote:

In rL325887#290689, @dim wrote:

Furthermore, we have read-only and read/write set_ sections. BFD ld and older lld seem to figure these out, then place the read-only ones just after .rodata, and the read/write ones after .data. I am not sure if there is a way to distinguish between these in a linker script? The names always match set_*, but there is no different naming scheme for r/o and r/w sets.

What I meant is to specify them explicitly. You do not need to match the 'set_*' for that.
I modified the script from the reproduce file in the following way (added all set_* r/w sections before _edata symbol assignment):

...
  .data1          : { *(.data1) }
  
  set_sysinit_set    : { *(set_sysinit_set) }
  set_sysuninit_set  : { *(set_sysuninit_set ) }
  set_pcpu           : { *(set_pcpu) }
  set_vnet           : { *(set_sysinit_set) }
  
  _edata = .; PROVIDE (edata = .);
...

And that resolves the issue (at least _edata == 01e2ef78 now, I did not check the booting).
I think the same should be done for the rest (r/o) set_* sections for the safety and overall correctness of the script.

Speaking about some kind of auto distinguishing between r/o and r/w, I do not think it is possible.
The script may have ONLY_IF_RO and ONLY_IF_RW commands, but that is
about different thing and will not help here I believe.

Will the suggested solution work for you?

In rL325887#290552, @grimar wrote:

Two questions:

1. Why don't you just list them in the script at the expected place? This will solve the issue and make the behavior explicit and cleaner I think.

This change breaks booting an lld-linked i386-freebsd kernel, apparently because it moves symbols around, while not updating the sections? For instance, with lld r325886, I have the following readelf output:

Ah, sorry about that! I should have realized this, but my CMake-fu is weak. :)

In D52240#1242341, @dim wrote:

Hmm, I tried on macOS 10.13.6 with Xcode 9.4.1 and Apple LLVM version 9.1.0 (clang-902.0.39.2), using stock libc++ r342744, but that already failed:

ninja: Entering directory `/Users/dim/obj/llvm-342744-trunk-darwin17-x86_64-ninja-rel-1'
[1/1] Testing ABI compatibility...
FAILED: projects/libcxx/lib/abi/CMakeFiles/check-cxx-abilist
cd /Users/dim/obj/llvm-342744-trunk-darwin17-x86_64-ninja-rel-1/projects/libcxx/lib/abi && /Users/dim/tmp/llvm/projects/libcxx/utils/sym_diff.py --only-stdlib-symbols --strict /Users/dim/tmp/llvm/projects/libcxx/lib/abi/x86_64-apple-darwin.v1.abilist /Users/dim/obj/llvm-342744-trunk-darwin17-x86_64-ninja-rel-1/lib/libc++.1.dylib
Symbol added: __ZNSt3__16__itoa8__u32toaEjPc
    {'type': 'FUNC', 'is_defined': True, 'name': '__ZNSt3__16__itoa8__u32toaEjPc'}

Symbol added: __ZNSt3__16__itoa8__u64toaEyPc
    {'type': 'FUNC', 'is_defined': True, 'name': '__ZNSt3__16__itoa8__u64toaEyPc'}

Summary
    Added:   2
    Removed: 0
    Changed: 0
Symbols added.

So I assume the ABI is already broken in some way...

In D52240#1239509, @ldionne wrote:

Marshall, can you confirm that the change does not break check-cxx-abilist on OS X. I'm fine with the change if that's not broken.

Built with mkdir build && cd build && cmake -G Ninja .. && ninja, the resulting libc++.so.1 has the following additional symbols:

So, any more actions to take, or can I commit this?

In D50297#1216935, @ruiu wrote:

Oh, I didn't notice that you are trying to make a change for i386, not for x86-64. What is your motivation to use superpages for 32-bit applications? I believe that the applications you want to use superpages are large programs and naturally be 64-bit, so I wonder if this change is actually useful.

Update all tests to match current output.

LGTM.

In D50297#1189621, @ruiu wrote:

Looking at this a bit more, I see that it is unconditionally setting the DefaultImage base for all platforms, which cannot be right. I didn't notice this when it was committed into FreeBSD, but it doesn't matter there, of course. I'm not sure if there is a good way to override this setting on a per-platform basis. Maybe just if (os == FreeBSD) DefaultImageBase=x?

Is there any reason that this value doesn't work for other operating systems? I guess the new image base values work everywhere. If that's the case, I'd change the default so that we have less moving parts in the linker.

@t.p.northover, I'm seeing this warning now on some code in FreeBSD, but the variable in question is perfectly aligned, so there should be no penalty at all. Does this warning check the actual variable being accessed in any way?

Looking at this a bit more, I see that it is unconditionally setting the DefaultImage base for all platforms, which cannot be right. I didn't notice this when it was committed into FreeBSD, but it doesn't matter there, of course. I'm not sure if there is a good way to override this setting on a per-platform basis. Maybe just if (os == FreeBSD) DefaultImageBase=x?

Ah, only now I've noticed that in the FreeBSD kernel link, we've been using the unsupported -z common-page-size= option:

Note that we have already committed this in FreeBSD, see https://reviews.freebsd.org/D16385 and https://reviews.freebsd.org/rS337282.

In D48806#1149655, @dim wrote:

In D48806#1149211, @devnexen wrote:

In D48806#1149021, @dim wrote:

Sorry for not getting to this one earlier, indeed it fixes the deadlock for me too!

Now the only "big" thing left is the hundreds of:

==41641==AddressSanitizer CHECK failed: /share/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:48 "((0)) == ((pthread_key_create(&tsd_key, destructor)))" (0x0, 0x4e)
`

failures. :-)

I guess it s FreeBSD 11.2 ? Seems his fix working on 10.4, will check on 11.x when I can ... otherwise there is always the thread local solution I threw a while ago. WE might need to come up with another solution anyway @krytarowski reports it is still an issue on NetBSD.

This is on FreeBSD 12-CURRENT, but it could also show the same issue on 11.x.

In D48806#1149211, @devnexen wrote:

In D48806#1149021, @dim wrote:

Sorry for not getting to this one earlier, indeed it fixes the deadlock for me too!

Now the only "big" thing left is the hundreds of:

==41641==AddressSanitizer CHECK failed: /share/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:48 "((0)) == ((pthread_key_create(&tsd_key, destructor)))" (0x0, 0x4e)
`

failures. :-)

I guess it s FreeBSD 11.2 ? Seems his fix working on 10.4, will check on 11.x when I can ... otherwise there is always the thread local solution I threw a while ago. WE might need to come up with another solution anyway @krytarowski reports it is still an issue on NetBSD.

Sorry for not getting to this one earlier, indeed it fixes the deadlock for me too!

FWIW, after this commit, on FreeBSD 12.0-CURRENT, most (if not all) ASan tests hang in 'urdlck' state. I'm still investigating.

Do we still leave the defaults for particular OSes here? I'm asking because for example in FreeBSD, we use libcxxrt, but you *won't* find it in linker output, since our libc++.so is a linker script:

$ clang++ /usr/local/share/cmake/Modules/DummyCXXFile.cxx -###
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0)
Target: x86_64-unknown-freebsd11.2
Thread model: posix
InstalledDir: /usr/bin
 "/usr/bin/clang++" "-cc1" "-triple" "x86_64-unknown-freebsd11.2" "-emit-obj" "-mrelax-all" "-disable-free" "-disable-llvm-verifier" "-discard-value-names" "-main-file-name" "DummyCXXFile.cxx" "-mrelocation-model" "static" "-mthread-model" "posix" "-mdisable-fp-elim" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu" "x86-64" "-dwarf-column-info" "-debugger-tuning=gdb" "-resource-dir" "/usr/lib/clang/6.0.0" "-internal-isystem" "/usr/include/c++/v1" "-fdeprecated-macro" "-fdebug-compilation-dir" "/home/dim/src/llvm/trunk" "-ferror-limit" "19" "-fmessage-length" "160" "-fobjc-runtime=gnustep" "-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-o" "/tmp/DummyCXXFile-5ffab3.o" "-x" "c++" "/usr/local/share/cmake/Modules/DummyCXXFile.cxx"
 "/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld-elf.so.1" "--hash-style=both" "--enable-new-dtags" "-o" "a.out" "/usr/lib/crt1.o" "/usr/lib/crti.o" "/usr/lib/crtbegin.o" "-L/usr/lib" "/tmp/DummyCXXFile-5ffab3.o" "-lc++" "-lm" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o"

E.g., you see -lc++, and our /usr/lib/libc++.so contains:

$ cat /usr/lib/libc++.so
/* $FreeBSD: stable/11/lib/libc++/libc++.ldscript 253917 2013-08-03 16:23:43Z dim $ */
GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so )

So what would check_link_libraries find in this case?

Use DeleteContainerSeconds instead of rolling our own.

Ping.

Sorry for reacting rather late to this, but I'm getting:

I'm fine with this, and also with committing it into FreeBSD's copy of lld, but I'd like to see the opinion of @ruiu and/or @grimar too. (I take it @espindola is no longer being monitored...)

Brooks, I can commit this if you prefer. Maybe it can go into 6.0.2 still...

In D45652#1078277, @emaste wrote:

Do we know why pthread_{get,set}specific fails now? And would it make sense to use tls more broadly (not just on FreeBSD)?

Ping

So, does this look good enough to commit?

Attempt to put the standard values in to definition lists. In the HTML
output, this looks fairly nice, but as a man page, it seems a bit
strange, for example:

In D45406#1060914, @mgorny wrote:

Well, my idea was to list the standards one per line (like on GCC manpage), and then the '(deprecated)' comments would probably stand out enough to apply to a single line. Also, FWICS the gcc manpage simply lists which aliases are deprecated in the description text. But skipping them entirely also works for me.

• Use "values" instead of "options"
• Remove deprecated standard values

In D45406#1060768, @mgorny wrote:

To be honest, I find those '(deprecated)' confusing — the user may mistakenly assume that it's about all values rather than the alias.

Interestingly, adding some debug prints to ConstantFoldFP seems to indicate the the NativeFP call *does* give the correct result:

Ping. Open to sugggestions here :)

LGTM

LGTM.

@rsmith, any objections?

I'm fine with either this approach, or with the approach in stdint.h, e.g. using __has_include_next(), and in that case first including the system-provided header before this one.

In D44536#1039420, @rjmccall wrote:

I'm not sure it's supposed to be a valid state to get into IRGen with a non-trivial destructor that isn't yet declared. Richard?

Update using @bdrewery's suggestion, with one small fix for Linux, where
Backtrace_LIBRARIES is usually an empty string.

Remove the __LAHFSAHF__ predefined macro.

LGTM.

Added the sahf feature for knm, knl and amdfam10 too.