https://sourceware.org/bugzilla/show_bug.cgi?id=29448
Dominique Martinet changed:
What|Removed |Added
CC||rfhn.fhbrrjnzeneqpf@noclue.
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
Dominique Martinet changed:
What|Removed |Added
CC||rfhn.fhbrrjnzeneqpf@noclue.
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #13 from Dominique Martinet ---
> See commit 1a26a53a0dee
That commit is about arm32, which apparently had the same problem, but aarch64
is in a similar place except that larger page sizes are actually used (I use
4K, but asahi li
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: rfhn.fhbrrjnzeneqpf at noclue dot notk.org
Target Milestone: ---
Creating a follow-up of what was discussed in
https://sourceware.org/bugzilla/show_bug.cgi?id=28824 after its
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #24 from Dominique Martinet ---
Hi all -- it's been a while and this bz tracks the original patch, not the
problem I reported, in hindsight I should have opened a new bz sorry.
I've done that just now: https://sourceware.org/bugzil
https://sourceware.org/bugzilla/show_bug.cgi?id=30612
--- Comment #5 from Dominique Martinet ---
(to be clear, I'm not dismissing the issue you pointed at for arm32 and agree
that commit is probably best reverted in the short term, I'm just asserting
that size increases still cause all sort of he
https://sourceware.org/bugzilla/show_bug.cgi?id=30612
--- Comment #4 from Dominique Martinet ---
> Is this truly a practical problem? Virtually every space-constrained system
> makes use of compressed firmware images, or has readily access to that
> tecnology.
We're using plain ext4 for the ro