Tue, Nov 20

I think this is the wrong direction, placing "common" code in addCXXStdlibLinkDeps, which then has all kinds of ugly ifs and switches for different OSes? Let different OSes handle this in their own way, maybe.

You mean handling this in individual ToolChain subclasses? I've considered doing that. The reason I went with a single method is because we already use this approach for other types of runtimes like sanitizers, XRay, etc. There'd be still some duplication for handling different C++ libraries, but I'd be fine changing the implementation to use that approach if there's a strong preference for doing so.

Mon, Nov 19

I think this is the wrong direction, placing "common" code in addCXXStdlibLinkDeps, which then has all kinds of ugly ifs and switches for different OSes? Let different OSes handle this in their own way, maybe.

Oct 11 2018

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.

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):

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.

Oct 1 2018

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:

Aug 29 2018

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.

Aug 7 2018

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.

Aug 4 2018

@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?

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.

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.

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.