Re: [PATCH fix PR71767 0/4] Background

[Jack Howarth <howarth dot at dot gcc at gmail dot com>]

What's up with the commit status on these proposed patches?

On Sun, Nov 6, 2016 at 2:36 PM, Iain Sandoe <iain@codesourcery.com> 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:
>  ….
>
> Lxxxx:
>   ….
>
>   pic reference to Lxxxx
>
> ld64 will split the object at “visible-global-weak” but it won’t see “Lxxxx” 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
>
>
>
>