On 17 May 2018, at 02:01, Dewayne Geraghty <dewayne.geraghty at
heuristicsystems.com.au> wrote:>
> On 17/05/2018 7:17 AM, Dimitry Andric wrote:
>> On 16 May 2018, at 15:54, Mike Tancsa <mike at sentex.net> wrote:
>>> On 5/15/2018 2:31 PM, Dimitry Andric wrote:
>>>> On 15 May 2018, at 20:22, Mike Tancsa <mike at
sentex.net> wrote:
>>>>>> Anyone else see this ?
>>>> See <https://bugs.freebsd.org/227552>. There is a fix
coming up.
>>> I tried the patch and did a full rebuild and it indeed fixed the
problem
>>> for me. Is the bug potentially more wide spread that just libxo ?
Also
>>> does it possibly affect amd64, just in a non obvious way ?
>> Yes to both, at least theoretically. The problem is actually in
>> elftoolchain's strip command, which can mess up the TLS section in
an
>> executable or shared library. When the dynamic linker loads such a bad
>> file, it will setup incorrect TLS data, which can lead to crashes.
>>
>> In case of libxo.so.0, this appears to have been caused by clang 6
>> giving a slightly different ELF layout than clang 5. During
buildworld,
>> libxo.so.0 is built with debugging information, which is later copied
>> to a libxo.so.0.debug file, while it is removed from the original
>> libxo.so.0 file.
>>
>> Up to this point, everything is still fine with libxo.so.0, still, but
>> during installworld, the file is stripped *again*, by install -s (this
>> is something we should revisit because it seems no longer useful).
This
>> second round of stripping messes up the TLS section.
>>
>> -Dimitry
>>
> Revisit? Perhaps, but it seems that its a regression against clang6 over
> clang5.
Well, my argument is that as long as any compiler and linker spit out a
valid ELF file, strip should not corrupt it. :)
And for certain, running strip twice on the same file should never
change it (except for maybe timestamp-related fields).
> Looking at
> https://svnweb.freebsd.org/base?view=revision&revision=333600
> its appears that the section flags are correctly applied now. When
> 333600 enters 11.1Beta?, do you think the build/installation process
> requires revision?
No, it should be enough to fix strip. In the installworld stage, the
copy of strip built during the cross-tools stage is used.
What I meant with revisiting this, is that historically we've stripped
executables and shared libraries during installworld, as those could
optionally have been built with debug information.
But since the introduction of /usr/lib/debug, this is no longer the
case: effectively, everything is built *with* debug information, and
this debug information is already stripped out and moved to separate
files during the buildworld stage.
Therefore, it is no longer necessary to strip those files again.
> Its a little disappointing to hear that the stripping process breaks the
> output, if applied >1.
And that was actually the bug. Note that this only happens for TLS
segments, which are not used very often. That is probably the reason
we never ran into problems before.
-Dimitry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20180517/8f2b85a9/attachment.sig>