What's up with the commit status on these proposed patches?
On Sun, Nov 6, 2016 at 2:36 PM, Iain Sandoe <i...@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 > > > >
