This is a follow up to yesterday's heads up regarding
the building of code that contains TLS on snv_106, the
text of which is included at the bottom of this message.
Read on if you are running a 64-bit X86 system attached
to an external SCSI enclosure.
ON also contains a small amount of TLS, specifically:
usr/src/lib/scsi/libses/common/ses_subr.c
This is part of FMA. If this code is linked by a link-editor
(ld) that contains the fix for
6773695 ld -z nopartial can break non-pic objects
and not
6792906 ld -z nopartial fix breaks TLS
then there is a chance that fmd might dump core if there is
an error while processing a SES target. This would not be a
kernel panic, but just a userland failure.
This affects amd64 systems connected to an external storage
enclosure that exports one or more SES (SCSI Enclosure Services)
targets. SES is described by the ses(7D) manpage. If you are running
such a system, you may want to avoid snv_106, or BFU to a newer
nightly build with the fix for 6792906.
- Ali
> This is a heads up for anyone building code that uses
> thread local storage (TLS) on X86 platforms. In particular,
> those building the SFW gate should read this message.
>
> The fix, in snv_106, for
>
> 6773695 ld -z nopartial can break non-pic objects
>
> contains a regression that causes the link-editor to incorrectly
> build 64-bit X86 (amd64) objects that use thread local storage (TLS).
> The SFW gate contains such code, so snv_106 cannot be used to build
> the SFW gate on X86 hardware.
>
> The fix for this issue has been integrated, and will appear
> in snv_107:
>
> 6792906 ld -z nopartial fix breaks TLS
>
> If you build code with TLS, you can avoid difficulty
> by taking one of the following actions:
>
> - Skip snv_106, and wait for snv_107
>
> - BFU to a nightly build that contains the fix
> for 6792906. That would be a nightly build
> from tonight (January 14, 2009) or later.
>
> - Use sparc hardware
>
> Sorry for the inconvenience.
>
> - Ali
