LLD default page size for arm32

Hello,

In the recent days we have been debugging a really thorny issue where binaries build with clang and linked with lld was just “Killed” when started on a specific armv7 device we ship on.

After quite a bit of head scratching it turns out that the kernel on this device ships with a 32k default page size (getconf PAGESIZE) and lld uses 4k default page size.

We fixed this by passing -zmax-page-size=0x10000 to lld.

The default page size in GNU ld for arm is 64k so binaries linked with ld just worked on this device.

I put the question in the discord lld channel and after a bit back and forth I think it’s better to discuss it here.

Is 4k the right default for lld on Arm32? Does anyone know if there is a strong reason to not change this?

Since we have a workaround I am not in a hurry to change this - but if nothing else I hope this email will help someone else finding the solution to the problem I had.

Thanks,
Tobias

Hello,

Is 4k the right default for lld on Arm32? Does anyone know if there is a strong reason to not change this?

At the time the Arm support for LLD was added, 4k page size was the overwhelming default for the major platforms that wanted to use LLD (largely those migrating from Gold which also uses 4k page size), including several that were quite size conscious and had reduced the page-size to 4k from the 64k default on AArch64 due to size concerns.

So a reason, whether it counts as strong or not, is that moving to 64k page size would mean a lot of users having to switch back to 4k pages.

Since we have a workaround I am not in a hurry to change this - but if nothing else I hope this email will help someone else finding the solution to the problem I had.

Thanks for reporting it. I think it will have to be a community decision. If the number of people with > 4k page size systems using LLD is very small and the number using 4k and care about the size is high, then it is may be more disruptive to change. However if there is a significant minority that do then it is worth changing to 64k for compatibility.

At the moment, based on the platforms that have adopted LLD so far, I think most have used 4k as this is the first problem report citing it. If the user base of LLD grows, with more platforms using a greater than 4k page size then it makes sense to aim for compatibility and raise the page size.

If you've got access would you be able to raise a PR with a title of something like Consider increasing LLD Arm default pagesize? We can collect opinions there.

Peter

Thanks for the reply Peter,

I have uploaded a diff to phab: https://reviews.llvm.org/D77330

-- Tobias

Thanks for the reply Peter,

I have uploaded a diff to phab: ⚙ D77330 Consider increasing the default ARM32 max page size to 64k.

-- Tobias

I asked Android, ChromeOS and FreeBSD arm folks for comments.

There should be no size impact for non-linker-script cases
after ⚙ D66749 [ELF][ARM] Allow PT_LOAD to have overlapping p_offset ranges on EM_ARM "[ELF][ARM] Allow PT_LOAD to have overlapping p_offset ranges on EM_ARM".

Hello,

Is 4k the right default for lld on Arm32? Does anyone know if there is a strong reason to not change this?

At the time the Arm support for LLD was added, 4k page size was the overwhelming default for the major platforms that wanted to use LLD (largely those migrating from Gold which also uses 4k page size), including several that were quite size conscious and had reduced the page-size to 4k from the 64k default on AArch64 due to size concerns.

So a reason, whether it counts as strong or not, is that moving to 64k page size would mean a lot of users having to switch back to 4k pages.

I believe the issues with binary size stemmed from the lack of support for common-page-size – which is now implemented – so this may not be an issue anymore.

Hello,

> Is 4k the right default for lld on Arm32? Does anyone know if there is a
strong reason to not change this?
>

At the time the Arm support for LLD was added, 4k page size was the
overwhelming default for the major platforms that wanted to use LLD
(largely those migrating from Gold which also uses 4k page size), including
several that were quite size conscious and had reduced the page-size to 4k
from the 64k default on AArch64 due to size concerns.

So a reason, whether it counts as strong or not, is that moving to 64k
page size would mean a lot of users having to switch back to 4k pages.

I believe the issues with binary size stemmed from the lack of support for
common-page-size -- which is now implemented -- so this may not be an issue
anymore.

In GNU ld and gold, common-page-size has an impact on the binary size
because they align the start of the first non-RELRO RW section to
common-page-size. This can create padding.

=9 (⚙ D58892 [ELF] Split RW PT_LOAD on the PT_GNU_RELRO boundary) uses a scheme of 2 RW PT_LOAD segments.

common-page-size does not have an impact on the size.

max-page-size does not have an impact on the size after -z
noseparate-code was made the default for all targets.

lld/ELF still has 3 cases where commonPageSize is used to decide
p_memsz. I suspect they can be dropped.

Hello,

Thanks for your input, it does sound like the 4k max page size made
sense when lld was initially built but that it would make sense for
compatibility reasons to increase it now. I added additional
information in phabricator this morning where I tested quite a few
things. Let me know if it makes sense to go ahead and start working on
the tests.

Btw, is there a way to batch update the tests from the output (as a
start) of each command instead of manually updating each value?

Thanks,
Tobias