[PATCH] D77330: Consider increasing the default ARM32 max page size to 64k.

[Peter Smith via Phabricator via llvm-commits]

psmith added a comment.

In D77330#1995415 <https://reviews.llvm.org/D77330#1995415>, @nathanchance wrote:

> In D77330#1994737 <https://reviews.llvm.org/D77330#1994737>, @psmith wrote:
>
> > In D77330#1994680 <https://reviews.llvm.org/D77330#1994680>, @nickdesaulniers wrote:
> >
> > > Hmm...seems to have regressed ARMv5 Linux kernel boots according to a bisection from @nathanchance (https://groups.google.com/g/clang-built-linux/c/aKDK-N6JN4g)
> >
> >
> > I don't think that URL is publicly visible.
>
>
> I don't know why that started happening :/
>
> > In theory increasing the max page size shouldn't have changed anything significant, especially given that ld.bfd defaults to the same page size, it may have flushed out another bug though. Would it be possible to raise a PR with a reproducer?
>
> Done: https://bugs.llvm.org/show_bug.cgi?id=45632
>
> Feel free to ping me for more information/debugging as needed.


Thanks for the PR. The change to the pagesize to 64k, along with the lowest starting address of 0xc0008000 has meant that LLD now thinks it can add allocate the headers, ELF header and  PT_PHDR in the first loadable segment. Other than that the only changes are the alignments of the program segments. At this point I don't know what is causing the problem. It is possible that the PT_PHDR and the extra program segment are confusing the boot-loader /compressor/decompressor.

ld.bfd with its 64k page size has a very different strategy for generating program headers. It generates 3 large program headers whereas LLD generates many smaller ones. I've put more details in the PR.

Anyhow I'm pretty sure that we've just flushed out another problem/difference between how LLD and BFD handle linker scripts that has turned out to cause a problem.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77330/new/

https://reviews.llvm.org/D77330