rtld-elf: Consistently use uintptr_t for TLS implementation

[jrtc27]

Summary

Elf_Addr is the format of addresses in the ELF file with the current
ABI's default class. This is normally the same as the format of an
address at run time, though technically exceptions do exist outside of
FreeBSD's currently-supported architectures (for example, IA-64's LP64
supports both ELFCLASS32 and ELFCLASS64 file formats; LP64 vs ILP32 is
an orthogonal EF_IA_64_ABI64 flag). On traditional architectures,
including all currently-supported FreeBSD architectures, addresses and
pointers are synonymous, but on CHERI they are not, as pointers are
capabilities that contain metadata alongside the address. In the cases
here, the quantities are run-time pointers, not addresses (and
definitely not ELF file addresses), so we should use pointer-ish types.

Note that we already use uintptr_t in struct tcb (both Variant I and
Variant II) but still use Elf_Addr in various places here (including
different argument types for tls_get_addr_slow and tls_get_addr_common).

Also use char * for addr rather than even uintptr_t, since most of the
time we want it to be an actual pointer.

[kib]

For me, Elf_Addr is more natural type synonym to use in the rtld code. Also, it gives us the luxury of Elf32/64_Addr typedefs, so if needed, multilib-like rtld has an easier way to express itself.

[jrtc27]

In D50226#1145753, @kib wrote:

For me, Elf_Addr is more natural type synonym to use in the rtld code. Also, it gives us the luxury of Elf32/64_Addr typedefs, so if needed, multilib-like rtld has an easier way to express itself.

Well, Elf_Addr is about the format of addresses within the ELF file, matching the default ELF class for the current ABI. Technically that does not have to match the format of addresses at run time (LP64 IA-64 used both ELFCLASS32 and ELFCLASS64; LP64 vs ILP32 was an orthogonal EF_IA_64_ABI64), though you probably shouldn't build a system that does that these days, and of course it definitely doesn't match the format of pointers for CHERI. The values here are not addresses in ELF files, they are pointers at run time, so they should use pointer types, and using anything other than (u)intptr_t or T * does not work on CHERI. We've already had to change this code downstream and whilst refactoring things upstream I'd like to take the time to use CHERI-compatible types rather than write new(ish) code that I know does not work for CHERI.

[kib]

In D50226#1145834, @jrtc27 wrote:

In D50226#1145753, @kib wrote:

For me, Elf_Addr is more natural type synonym to use in the rtld code. Also, it gives us the luxury of Elf32/64_Addr typedefs, so if needed, multilib-like rtld has an easier way to express itself.

Well, Elf_Addr is about the format of addresses within the ELF file, matching the default ELF class for the current ABI. Technically that does not have to match the format of addresses at run time (LP64 IA-64 used both ELFCLASS32 and ELFCLASS64; LP46 vs ILP32 was an orthogonal EF_IA_64_ABI64), though you probably shouldn't build a system that does that these days, and of course it definitely doesn't match the format of pointers for CHERI. The values here are not addresses in ELF files, they are pointers at run time, so they should use pointer types, and using anything other than (u)intptr_t or T * does not work on CHERI. We've already had to change this code downstream and whilst refactoring things upstream I'd like to take the time to use CHERI-compatible types rather than write new(ish) code that I know does not work for CHERI.

I think this opinion should be stated in the change' summary.

[jrtc27]

In D50226#1145838, @kib wrote:

In D50226#1145834, @jrtc27 wrote:

In D50226#1145753, @kib wrote:

For me, Elf_Addr is more natural type synonym to use in the rtld code. Also, it gives us the luxury of Elf32/64_Addr typedefs, so if needed, multilib-like rtld has an easier way to express itself.

Well, Elf_Addr is about the format of addresses within the ELF file, matching the default ELF class for the current ABI. Technically that does not have to match the format of addresses at run time (LP64 IA-64 used both ELFCLASS32 and ELFCLASS64; LP46 vs ILP32 was an orthogonal EF_IA_64_ABI64), though you probably shouldn't build a system that does that these days, and of course it definitely doesn't match the format of pointers for CHERI. The values here are not addresses in ELF files, they are pointers at run time, so they should use pointer types, and using anything other than (u)intptr_t or T * does not work on CHERI. We've already had to change this code downstream and whilst refactoring things upstream I'd like to take the time to use CHERI-compatible types rather than write new(ish) code that I know does not work for CHERI.

I think this opinion should be stated in the change' summary.

Thanks. Are you happy with the updated description?

[kib]

In D50226#1145856, @jrtc27 wrote:

In D50226#1145838, @kib wrote:

In D50226#1145834, @jrtc27 wrote:

In D50226#1145753, @kib wrote:

For me, Elf_Addr is more natural type synonym to use in the rtld code. Also, it gives us the luxury of Elf32/64_Addr typedefs, so if needed, multilib-like rtld has an easier way to express itself.

Well, Elf_Addr is about the format of addresses within the ELF file, matching the default ELF class for the current ABI. Technically that does not have to match the format of addresses at run time (LP64 IA-64 used both ELFCLASS32 and ELFCLASS64; LP46 vs ILP32 was an orthogonal EF_IA_64_ABI64), though you probably shouldn't build a system that does that these days, and of course it definitely doesn't match the format of pointers for CHERI. The values here are not addresses in ELF files, they are pointers at run time, so they should use pointer types, and using anything other than (u)intptr_t or T * does not work on CHERI. We've already had to change this code downstream and whilst refactoring things upstream I'd like to take the time to use CHERI-compatible types rather than write new(ish) code that I know does not work for CHERI.

I think this opinion should be stated in the change' summary.

Thanks. Are you happy with the updated description?

Is it LP46 or LP64?
Yes, I think that the updated text provides better motivation for the change. Thank you.

[jrtc27]

In D50226#1145897, @kib wrote:

In D50226#1145856, @jrtc27 wrote:

In D50226#1145838, @kib wrote:

In D50226#1145834, @jrtc27 wrote:

In D50226#1145753, @kib wrote:

For me, Elf_Addr is more natural type synonym to use in the rtld code. Also, it gives us the luxury of Elf32/64_Addr typedefs, so if needed, multilib-like rtld has an easier way to express itself.

Well, Elf_Addr is about the format of addresses within the ELF file, matching the default ELF class for the current ABI. Technically that does not have to match the format of addresses at run time (LP64 IA-64 used both ELFCLASS32 and ELFCLASS64; LP46 vs ILP32 was an orthogonal EF_IA_64_ABI64), though you probably shouldn't build a system that does that these days, and of course it definitely doesn't match the format of pointers for CHERI. The values here are not addresses in ELF files, they are pointers at run time, so they should use pointer types, and using anything other than (u)intptr_t or T * does not work on CHERI. We've already had to change this code downstream and whilst refactoring things upstream I'd like to take the time to use CHERI-compatible types rather than write new(ish) code that I know does not work for CHERI.

I think this opinion should be stated in the change' summary.

Thanks. Are you happy with the updated description?

Is it LP46 or LP64?
Yes, I think that the updated text provides better motivation for the change. Thank you.

Oops, obvious typo that I then copied