What's up with the commit status on these proposed patches?
On Sun, Nov 6, 2016 at 2:36 PM, Iain Sandoe wrote:
> Hi Folks,
>
> Including Jeff on the cc since we were discussing this on Friday (and it’s
> not 100% clear who’s reviewing configury patches at present).
> Including Uros, because there’s one minor change to i386/i386.c
>
> PR71767 is " Endless stream of warnings when using GCC with -Wa,-q and Clang
> Integrated Assembler”.
> ** we are talking 40k testsuite fails, so this is a show-stopper for current
> toolchains.
>
> Actually, what’s happened is that recent xcode tools have started to issue a
> warning about deprecated use of a mechanism to support coalesced symbols by
> using separate sections with specific attributes in the (ancient) days before
> the static linker supported them directly. We need to catch up since
> deprecation will no doubt be followed by removal.
>
> Essentially, now that the linker is capable of dealing with such things, the
> right solution is to emit them into the regular sections and drop the use of
> the coalesced ones. This has been possible for some time, and Xcode is now
> flagging that it’s time to tidy up and drop the old mechanism.
>
> However,
>
> A. this is only true when the “binutils” (cctools + ld64) are sufficiently
> new to support it.
> - so the solution needs to be made to depend on the version of ld64 in use.
>
> B. more importantly, it reveals some cases where the ld64 atom model*** will
> be violated when symbols are concatenated such that weak globals and non-weak
> locals can be confused.
> - we need to fix this before we can apply A
>
> C. it makes a secondary variant of pr57438 fire more often (when switches
> contain trailing cases with __builtin_unreachable() resulting in trailing
> local symbols with jump-table references, that potentially have the same
> address as a following weak global). That might seem improbable, but c++
> with case statements with an unreachable default manage to hit it...
> - I’ll post for this separately, but noting it in passing.
>
>
>
> *** The ld64 atom model summary;
>
> Instead of using -ffunction-sections/-fdata-sections, Darwin’s linker has a
> different model of partitioning the input objects such that they might be
> rearranged to minimise displacements, and to identify dead code that may be
> stripped (in a similar manner to —gc-sections).
>
> Input binaries to ld64 are automatically partitioned into “atoms”;
> an atom is defined as “a section of code or data beginning with a
> linker-visible symbol and of non-zero size”.
>
> These “atoms” have the properties of their initial symbol and may be
> rearranged and dead-stripped.
>
> — the general problem is that we might have a situation where we have:
>
> visible-global-weak:
> ….
>
> L:
> ….
>
> pic reference to L
>
> ld64 will split the object at “visible-global-weak” but it won’t see “L”
> and so the pic reference will appear to point into the visible-global-weak
> atom, [which is not allowed without indirection (to support interposing)].
>
> Of course, that’s a false-positive complaint - but ld64 can’t see the other
> place to split.
>
> This is solved in other Darwin toolchains by making the “L” into “l” in such
> cases; lower-case “l” is not hidden by the assembler, and thus the linker
> can see it and split the second section of code into its own ‘non-weak’ atom;
> everyone’s happy. Of course, we don’t want to do this unnecessarily, since
> it’s inefficient from the PoV of extra symbols.
>
> linker-visible symbols made this way will not be retained in the final linked
> entity (dso or exe).
>
> So:
>
> Patch 1: implements the changes to modify L => l in the relevant places.
>
> Patch 2: Adds configury to specify or detect that the linker is ld64 (or
> compatible) and to determine its version; there’s a fall-back to allow the
> version to be specified by someone doing a native or Canadian cross.
>
> Patch 3: Is the actual fix that switches the section use to ‘regular’ for
> sufficiently modern ld64 (there’s a minor change to i386/i386.c)
>
> Patch 4: (Mostly Dominique’s work) fixes up the testsuite fallout.
>
> This has been tested across the Darwin patch - from powerpc-darwin9 -
> x86_64-apple-darwin16 and I did a bootstrap and check on x86_64-linux-gnu.
>
> The patches could be applied one at a time - but N typically depends on N-1 -
> so the sequence of application needs to follow this.
>
> Iain
>
>
>
>