Hello, On Mon, Mar 25, 2024 at 2:58 PM Florian Weimer <fwei...@redhat.com> wrote: > > I think the intent here is to initialize _dl_pagesize with a > > conservative default, to avoid initialization ordering issues. > > EXEC_PAGESIZE is supposed to be largest supported page size. > > This was committed without addressing the comment above.
yes, I also didn't expect this to get pushed until we come to an agreement here. On topic: I understand that this must have been done this way because of potential initialization order issues (and the mail I linked also makes this guess). The question is, is that (working around initialization order issues) actually required, or is that a leftover from something that's no longer relevant (or perhaps never was)? Things seem to still work with this patch on aarch64-gnu for me, both in SHARED and !SHARED, though I obviously didn't test every potential codepath. I was hoping that some broader testing, such as running the testsuite on CI on existing ports, could answer that question comprehensively -- though now I realize that since this patch leaves the initialization as-is when EXEC_PAGESIZE is defined (i.e. everywhere but on aarch64-gnu), CI wouldn't catch any issues that removing it would cause. 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. Sergey