public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Tatsuyuki Ishi <ishitatsuyuki@gmail.com>
To: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
Cc: libc-alpha@sourceware.org, Rui Ueyama <rui314@gmail.com>,
	Rui Ueyama <ruiu@bluewhale.systems>,
	schwab@linux-m68k.org
Subject: Re: [PATCH v3] RISC-V: Implement TLS Descriptors.
Date: Thu, 14 Sep 2023 17:39:55 +0900	[thread overview]
Message-ID: <9600C568-8A5B-457C-B726-D62D8C1EF226@gmail.com> (raw)
In-Reply-To: <93e0270b-bdc8-3443-1d2a-947a31945d99@linaro.org>

[-- Attachment #1: Type: text/plain, Size: 3770 bytes --]


> On Sep 14, 2023, at 4:14, Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> wrote:
> 
> 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’m sorry I’ve made multiple mistakes here. There were actually two prerequisite commits but I’ve forgot to include them in the patch series. This will be included in v4.

I used [1] to build a full toolchain and it defaulted to --disable-werror. I’ve manually enabled -Werror and fixed all compiler warnings in v4.

As for have-mtls-dialect-gnu2, RISC-V will use AArch64-style flags (-mtls-dialect={trad,desc}), not gnu2. However, I have configured my GCC fork with --with-tls=desc and all compilation is done with TLSDESC by default for my testing.

I assumed most testing was done through GCC’s testsuite, and I’ve got GCC’s testsuite to the point of no regression, however I was wrong and there are more in glibc’s testsuite. For v4 I’ve ran all tests in glibc/elf/, and all but two tests for TLS on static executables are passing. More info on my plan for fixing that in v4.

> 
>> # RISC-V's assembler also needs to know about PIC as it changes the definition
>> # of some assembler macros.
>> ASFLAGS-.os += $(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.
> 
> 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) == R_RISCV_COPY)))
>> 
>> /* Return nonzero iff ELF header is compatible with the running host.  */
>> @@ -219,6 +221,32 @@ elf_machine_rela (struct link_map *map, struct r_scope_elem *scope[],
>> 	}
>>       break;
>> 
>> +    case R_RISCV_TLSDESC:
>> +      struct tlsdesc *td = (struct tlsdesc *) addr_field;
>> +      if (sym == NULL)
>> +	{
>> +	  td->entry = _dl_tlsdesc_undefweak;
> 
> 
> This triggers multiple compiler warnings:
> 
> ../sysdeps/riscv/dl-machine.h: In function ‘elf_machine_rela’:
> ../sysdeps/riscv/dl-machine.h:228:21: error: assignment to ‘ptrdiff_t (*)(struct tlsdesc *)’ {aka ‘long int (*)(struct tlsdesc *)’} from incompatible pointer type ‘long unsigned int (*)(struct tlsdesc *)’ [-Werror=incompatible-pointer-types]
>  228 |           td->entry = _dl_tlsdesc_undefweak;
>      |                     ^
> ../sysdeps/riscv/dl-machine.h:244:25: error: assignment to ‘ptrdiff_t (*)(struct tlsdesc *)’ {aka ‘long int (*)(struct tlsdesc *)’} from incompatible pointer type ‘long unsigned int (*)(struct tlsdesc *)’ [-Werror=incompatible-pointer-types]
>  244 |               td->entry = _dl_tlsdesc_return;
>      |                         ^
> 
> Because you declare _dl_tlsdesc_undefweak as:
> 
>  unsigned long _dl_tlsdesc_dynamic (struct tlsdesc *);
> 
> But the 'entry' at tlsdesc as:
> 
>   ptrdiff_t (*entry) (struct tlsdesc *);
> 
> Based on TLSDESC ABI I think using a unsigned as return value is wrong here.

I am opting to not using ptrdiff_t because the offset can be larger than PTRDIFF_MAX. Using unsigned arithmetic avoids the signed overflow concern.

The descriptor signature is also defined in the RISC-V psABI as returning unsigned long for the same reason.

[1]: https://github.com/riscv-collab/riscv-gnu-toolchain


  reply	other threads:[~2023-09-14  8:40 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-17 18:12 [PATCH] " Tatsuyuki Ishi
2023-08-17 18:35 ` Andreas Schwab
2023-09-08 10:55 ` [PATCH v2] " Tatsuyuki Ishi
2023-09-13 17:26 ` [PATCH v3] " Tatsuyuki Ishi
2023-09-13 19:14   ` Adhemerval Zanella Netto
2023-09-14  8:39     ` Tatsuyuki Ishi [this message]
2023-09-14 12:09       ` Adhemerval Zanella Netto
2024-01-27  2:22         ` Fangrui Song
2023-09-13 19:07 ` [PATCH] " Andrew Waterman
2023-09-14  8:40 ` [PATCH v4 0/3] " Tatsuyuki Ishi
2023-09-14  8:40   ` [PATCH v4 1/3] RISC-V: Add include guard for dl-tls.h Tatsuyuki Ishi
2024-01-27  1:14     ` Fangrui Song
2023-09-14  8:40   ` [PATCH v4 2/3] RISC-V: Add TLSDESC reloc definitions Tatsuyuki Ishi
2024-01-27  1:12     ` Fangrui Song
2023-09-14  8:40   ` [PATCH v4 3/3] RISC-V: Implement TLS Descriptors Tatsuyuki Ishi
2023-11-23 11:39     ` Florian Weimer
2024-03-29  5:55 ` [PATCH v5 0/3] " Tatsuyuki Ishi
2024-03-29  5:55   ` [PATCH v5 1/3] RISC-V: Add include guard for dl-tls.h Tatsuyuki Ishi
2024-03-29  5:55   ` [PATCH v5 2/3] RISC-V: Add TLSDESC reloc definitions Tatsuyuki Ishi
2024-03-29  5:55   ` [PATCH v5 3/3] RISC-V: Implement TLS Descriptors Tatsuyuki Ishi
2024-03-29  6:18 ` [PATCH v6 0/3] " Tatsuyuki Ishi
2024-03-29  6:18   ` [PATCH v6 1/3] RISC-V: Add include guard for dl-tls.h Tatsuyuki Ishi
2024-04-03 11:48     ` Adhemerval Zanella Netto
2024-03-29  6:18   ` [PATCH v6 2/3] RISC-V: Add TLSDESC reloc definitions Tatsuyuki Ishi
2024-04-03  5:10     ` Fangrui Song
2024-04-03  8:03     ` Andreas Schwab
2024-03-29  6:18   ` [PATCH v6 3/3] RISC-V: Implement TLS Descriptors Tatsuyuki Ishi
2024-04-01 13:23     ` Florian Weimer
2024-04-01 19:29     ` Adhemerval Zanella Netto
2024-04-02  3:36       ` Tatsuyuki Ishi
2024-04-02 13:35         ` Adhemerval Zanella Netto
2024-04-02 15:25           ` Palmer Dabbelt
2024-04-02 15:32             ` Adhemerval Zanella Netto
2024-04-02 16:37               ` Palmer Dabbelt
2024-04-30 17:05   ` [PATCH v6 0/3] " Palmer Dabbelt
2024-04-30 18:33     ` Adhemerval Zanella Netto
2024-05-01  1:36       ` Tatsuyuki Ishi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9600C568-8A5B-457C-B726-D62D8C1EF226@gmail.com \
    --to=ishitatsuyuki@gmail.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=libc-alpha@sourceware.org \
    --cc=rui314@gmail.com \
    --cc=ruiu@bluewhale.systems \
    --cc=schwab@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).