From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by sourceware.org (Postfix) with ESMTPS id 384C63858D20 for ; Thu, 14 Sep 2023 08:40:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 384C63858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-1c39500767aso1391575ad.0 for ; Thu, 14 Sep 2023 01:40:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694680809; x=1695285609; darn=sourceware.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=eBtQ6sKhPQS++RkN007WhHblHE1nS7t4hMjTBSnnV74=; b=W0iqH1lsk1d+msmxUsJ2rE7sLjra9LXVlgR2fkYzhA+62+kgCXV8oCF8Frad2sRf0r i5FqHNED8SmlFabzzWX622BLatzO4lVuD250lalp1tnuxKXk2LLAuxyDtUBMqB8lED95 vY+wqpjrdwo9LKwtMtMykDXxcr4yicUWgDlfP9HatEb4hklTx621DXqK3DuWjU1efYWH PWK8pBPKXPcg7Y9uZEcLo4rshnY6GEKGINfy9mG8jjhh9Qw/3/VYY1Cugc2rZmjGbJMC pRmKG6Z+XcR5vv92NrIMlad5yCZpvutFz91lEtKfSyzMdTwNx6bNgEq4PJ5elgwH1r4C G/ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694680809; x=1695285609; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=eBtQ6sKhPQS++RkN007WhHblHE1nS7t4hMjTBSnnV74=; b=tS6asT4Rrna6URC/QZcBN0EWtnxFY3SFGNMyyAKKDqzLxrKNyHWqg3yEHhVxzsEZT7 5weC7VFIk6f15weCF8ZeIuVOXSgqVuIpCUU9sdFZ7nQBnhxEv9ZI+VF/kXUXQGqNDIhX jS8miicd1iMkIb72rRdzuY0tAug1xR+jXuOy/fjOt57Aqg4di0YM6UlnWAgoo95tMlMM 4Jm12fOXB45abTYs6igDxrk32h0fzzTpi4sjx+M18Luo84L1budp6Stvrg0BgZ8okZiP ws8k66iNgTEl3WJP6Q50BX2SvzmTJUhOWqCB7JRtA3uQIfNrc5cxUWRocWgE+MwCJMFf oX0g== X-Gm-Message-State: AOJu0YzV+zo7Ku2i28sjChLNdkwGlVzKda67aTXV8NkQgWbF5EuFmXMp 6qxT98lmL5a4s/MLDI8JuGU= X-Google-Smtp-Source: AGHT+IH6ULVyhSVK0jrRuT6urdCPgs7uHwd/53egVH6echu1aa67U/6OwvfQGYEdOdmK+mf8acnLmw== X-Received: by 2002:a17:903:22cb:b0:1c1:fc5c:b34a with SMTP id y11-20020a17090322cb00b001c1fc5cb34amr5474564plg.3.1694680808981; Thu, 14 Sep 2023 01:40:08 -0700 (PDT) Received: from smtpclient.apple (zz20184013906F627101.userreverse.dion.ne.jp. [111.98.113.1]) by smtp.gmail.com with ESMTPSA id y18-20020a170902ed5200b001bf846dd2ebsm1003568plb.303.2023.09.14.01.40.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Sep 2023 01:40:08 -0700 (PDT) From: Tatsuyuki Ishi Message-Id: <9600C568-8A5B-457C-B726-D62D8C1EF226@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9751BB2C-CE39-4CA0-A0F8-A9A512D299BB" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: [PATCH v3] RISC-V: Implement TLS Descriptors. Date: Thu, 14 Sep 2023 17:39:55 +0900 In-Reply-To: <93e0270b-bdc8-3443-1d2a-947a31945d99@linaro.org> Cc: libc-alpha@sourceware.org, Rui Ueyama , Rui Ueyama , schwab@linux-m68k.org To: Adhemerval Zanella Netto References: <20230817181228.122674-2-ishitatsuyuki@gmail.com> <20230913172633.39229-1-ishitatsuyuki@gmail.com> <93e0270b-bdc8-3443-1d2a-947a31945d99@linaro.org> X-Mailer: Apple Mail (2.3731.700.6) X-Spam-Status: No, score=-11.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --Apple-Mail=_9751BB2C-CE39-4CA0-A0F8-A9A512D299BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 14, 2023, at 4:14, Adhemerval Zanella Netto wrote: >=20 > How did you actually build glibc? I saw multiple build issues with default > configuration and even with --disable-werror, so I am doubtful that this > patch was really proper tested. Please ensure that have-mtls-dialect-gnu2 > is set to 'yes' on config.make so the tests are actually run. I=E2=80=99m sorry I=E2=80=99ve made multiple mistakes here. There were actu= ally two prerequisite commits but I=E2=80=99ve forgot to include them in th= e patch series. This will be included in v4. I used [1] to build a full toolchain and it defaulted to --disable-werror. = I=E2=80=99ve manually enabled -Werror and fixed all compiler warnings in v4. As for have-mtls-dialect-gnu2, RISC-V will use AArch64-style flags (-mtls-d= ialect=3D{trad,desc}), not gnu2. However, I have configured my GCC fork wit= h --with-tls=3Ddesc and all compilation is done with TLSDESC by default for= my testing. I assumed most testing was done through GCC=E2=80=99s testsuite, and I=E2= =80=99ve got GCC=E2=80=99s testsuite to the point of no regression, however= I was wrong and there are more in glibc=E2=80=99s testsuite. For v4 I=E2= =80=99ve ran all tests in glibc/elf/, and all but two tests for TLS on stat= ic executables are passing. More info on my plan for fixing that in v4. >=20 >> # RISC-V's assembler also needs to know about PIC as it changes the defi= nition >> # of some assembler macros. >> ASFLAGS-.os +=3D $(pic-ccflag) >> diff --git a/sysdeps/riscv/dl-lookupcfg.h b/sysdeps/riscv/dl-lookupcfg.h >> new file mode 100644 >> index 0000000000..d7fe73636b >> --- /dev/null >> +++ b/sysdeps/riscv/dl-lookupcfg.h >> @@ -0,0 +1,27 @@ >> +/* Configuration of lookup functions. >> + Copyright (C) 2006-2023 Free Software Foundation, Inc. >=20 > I think it should be only 2023 for new code. Ack, all copyright headers for new files will be 2023 only in v4. >> | (ELF_RTYPE_CLASS_COPY * ((type) =3D=3D R_RISCV_COPY))) >>=20 >> /* Return nonzero iff ELF header is compatible with the running host. */ >> @@ -219,6 +221,32 @@ elf_machine_rela (struct link_map *map, struct r_sc= ope_elem *scope[], >> } >> break; >>=20 >> + case R_RISCV_TLSDESC: >> + struct tlsdesc *td =3D (struct tlsdesc *) addr_field; >> + if (sym =3D=3D NULL) >> + { >> + td->entry =3D _dl_tlsdesc_undefweak; >=20 >=20 > This triggers multiple compiler warnings: >=20 > ../sysdeps/riscv/dl-machine.h: In function =E2=80=98elf_machine_rela=E2= =80=99: > ../sysdeps/riscv/dl-machine.h:228:21: error: assignment to =E2=80=98ptrdi= ff_t (*)(struct tlsdesc *)=E2=80=99 {aka =E2=80=98long int (*)(struct tlsde= sc *)=E2=80=99} from incompatible pointer type =E2=80=98long unsigned int (= *)(struct tlsdesc *)=E2=80=99 [-Werror=3Dincompatible-pointer-types] > 228 | td->entry =3D _dl_tlsdesc_undefweak; > | ^ > ../sysdeps/riscv/dl-machine.h:244:25: error: assignment to =E2=80=98ptrdi= ff_t (*)(struct tlsdesc *)=E2=80=99 {aka =E2=80=98long int (*)(struct tlsde= sc *)=E2=80=99} from incompatible pointer type =E2=80=98long unsigned int (= *)(struct tlsdesc *)=E2=80=99 [-Werror=3Dincompatible-pointer-types] > 244 | td->entry =3D _dl_tlsdesc_return; > | ^ >=20 > Because you declare _dl_tlsdesc_undefweak as: >=20 > unsigned long _dl_tlsdesc_dynamic (struct tlsdesc *); >=20 > But the 'entry' at tlsdesc as: >=20 > ptrdiff_t (*entry) (struct tlsdesc *); >=20 > Based on TLSDESC ABI I think using a unsigned as return value is wrong he= re. I am opting to not using ptrdiff_t because the offset can be larger than PT= RDIFF_MAX. Using unsigned arithmetic avoids the signed overflow concern. The descriptor signature is also defined in the RISC-V psABI as returning u= nsigned long for the same reason. [1]: https://github.com/riscv-collab/riscv-gnu-toolchain --Apple-Mail=_9751BB2C-CE39-4CA0-A0F8-A9A512D299BB--