From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI,
	RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 28772 invoked from network); 6 Oct 2023 04:20:33 -0000
Received: from second.openwall.net (193.110.157.125)
  by inbox.vuxu.org with ESMTPUTF8; 6 Oct 2023 04:20:33 -0000
Received: (qmail 5440 invoked by uid 550); 6 Oct 2023 04:20:30 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 5402 invoked from network); 6 Oct 2023 04:20:29 -0000
Date: Fri, 6 Oct 2023 00:20:25 -0400
From: Rich Felker <dalias@libc.org>
To: Rui Ueyama <rui314@gmail.com>
Cc: musl@lists.openwall.com
Message-ID: <20231006042025.GI4163@brightrain.aerifal.cx>
References: <CACKH++Yq3LGXGaUBrR4BupwPkPmH4bDjFrRNEDwbLTh1nKqC1w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACKH++Yq3LGXGaUBrR4BupwPkPmH4bDjFrRNEDwbLTh1nKqC1w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [musl] arm32 tlsdesc bug

On Fri, Oct 06, 2023 at 01:08:18PM +0900, Rui Ueyama wrote:
> Hi,
> 
> I think there's a bug in musl's TLSDESC implementation for ARM32.
> 
> TLSDESC uses two consecutive GOT slots to store a function pointer and its
> argument. Usually, the function pointer is stored in the first slot and the
> argument in the second. However, on ARM32, the order is reversed; the
> argument is stored in the first slot.
> 
> If a TLSDESC relocation has a non-zero addend, it's applied to the function
> argument and not to the function pointer. That means, for an ABI that uses
> the REL-type relocations (as opposed to RELA-type), the addend should be
> stored to the location where the function argument is stored, and that's
> the first slot on ARM32.
> 
> So, I believe we need something like this.
> 
> diff --git a/ldso/dynlink.c b/ldso/dynlink.c
> index ceca3c98..254fa5b8 100644
> --- a/ldso/dynlink.c
> +++ b/ldso/dynlink.c
> @@ -513,11 +513,17 @@ static void do_relocs(struct dso *dso, size_t *rel,
> size_t rel_size, size_t stri
>                 case REL_TPOFF_NEG:
>                         *reloc_addr = def.dso->tls.offset - tls_val +
> addend;
>                         break;
>  #endif
>                 case REL_TLSDESC:
> -                       if (stride<3) addend = reloc_addr[1];
> +                       if (stride<3) {
> +#ifdef TLSDESC_BACKWARDS
> +                               addend = reloc_addr[0];
> +#else
> +                               addend = reloc_addr[1];
> +#endif
> +                       }
>                         if (def.dso->tls_id > static_tls_cnt) {
>                                 struct td_index *new = malloc(sizeof *new);
>                                 if (!new) {
>                                         error(
>                                         "Error relocating %s: cannot
> allocate TLSDESC for %s",

Thank you!! This almost surely explains the TLSDESC problems we've
encountered on arm (32-bit) that prevented enabling it by default.

Rich