Hello, On Wed, Apr 10, 2024 at 2:57 PM Florian Weimer <fwei...@redhat.com> wrote: > * Sergey Bugaev: > > > We could define EXEC_PAGESIZE to some conservative value on > > aarch64-gnu too, if it turns out that this little workaround is really > > required. But it seems cleaner to make sure we don't need to, as > > Roland's email suggests, and introducing a new port that doesn't have > > a fixed page size (and doesn't come with an EXEC_PAGESIZE value > > already defined in kernel headers) seems to be a good opportunity to > > do that. That's my reasoning here. > > But the ELF image must be laid out with certain expectations regarding > the maximum support page size. Otherwise, something (kernel or dynamic > linker) needs to perform copies or upgrade conflicting permissions > within one page to a superset of all permissions. I don't think we have > code for that today, and we wouldn't necessarily want to implement that, > I think.
Certainly -- and I wouldn't expect the kernel or the dynamic linker to do anything about it other than reporting an error. I think what you're saying is you consider EXEC_PAGESIZE to indeed describe/define this required alignment of ELF segments (as the name suggests). If I adopt that view, then yes, having EXEC_PAGESIZE makes sense, and it makes some sense to use it as a conservative page size value to use while the real value is not yet available (assuming there is a real need for that). The way I've been viewing it -- based on the fact that neither Linux's nor glibc's (dynamic) nor BFD's nor LLVM's (static) linkers use it for that purpose -- is that it's just some PAGE_SIZE-like definition that's unrelated to binary loading (despite its name -- perhaps it has been historically related to segment alignment in some old versions of Linux?) that has been co-opted by glibc for pre-initializing dl_pagesize, for dubious reasons. It also seems to be a Linux- (and x86 Hurd) specific thing; I cannot find it in the BSDs. Which one is it? Sergey
