Or, like WITNESS or MALLOC_PRODUCTION, on in HEAD and off in stable branches?

Seems sensible to me

Hm, binutils should still be defaulting to -znostart-stop-gc even today in their master branch. So this really should be a no-op, this shouldn't be the cause of any issues. (Unless sjg is building with some modified environment that overrides that default, I suppose, but that's shooting oneself in the foot...)

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.

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.

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.

Only include libc changes

In D50186#1144833, @kib wrote:

In D50186#1144828, @kib wrote:

Or instead, re-set the tls_max_index to 0 for direct exec mode before calling map_object()?

Then this would also require a fixup after the map_object() call, for the case where the main obj does not have TLS init segment.

Update documentation

In D35355#1142282, @emaste wrote:

It appears this is responsible for a regression, see PR 286079

In D50078#1142220, @emaste wrote:

This is fine with me. I'll cc @christos_netbsd.org in case NetBSD would like to make an equivalent change (or maybe they already have one?)

Add comment about host vs target

Thank you!

This isn't going to suffice. If you update your SDK to one that knows about 15.4 or later then you'll have the prototype in string.h and __MAC_OS_X_VERSION_MAX_ALLOWED will be 15.4 or higher, but we won't provide this implementation, so at compile time you'll get warning: 'strchrnul' is only available on macOS 15.4 or newer [-Wunguarded-availability-new] and at run time you'll get a segmentation fault from the symbol stub (Mach-O PLT-like thing) branching to NULL.

What about with clang++? Otherwise the driver won't link in libc++.

Oh, yes, I failed to spot that in the review but this was clearly wrong and a no-op

Well this is just wrong, boot services data can be reclaimed once you've exited boot services. Linux seems to work because it always honours the FDT's reserved memory regions, so we should follow that to work around this broken firmware (in fact AFAICT Linux doesn't even bother to parse the table, even on arm64, which is surprising... not sure how ACPI ends up working). And please report a bug against the firmware in question so this can actually get fixed to correctly mark it as EfiRuntimeServicesCode/Data or EfiReservedMemoryType.