On Android we frequently find that the linker loads Firefox' libxul.so with holes in it. These corresponds to areas that have been reserved by the linker but weren't actually mapped for some reason. See below for an example of how these mappings look like:
9b4a0000-9b931000 r--p 00000000 08:12 393449 /data/app/org.mozilla.firefox-1/lib/x86/libxul.so
9b931000-9bcae000 ---p 00000000 00:00 0
9bcae000-a116b000 r-xp 00490000 08:12 393449 /data/app/org.mozilla.firefox-1/lib/x86/libxul.so
a116b000-a4562000 r--p 0594d000 08:12 393449 /data/app/org.mozilla.firefox-1/lib/x86/libxul.so
a4562000-a4563000 ---p 00000000 00:00 0
a4563000-a4840000 r--p 08d44000 08:12 393449 /data/app/org.mozilla.firefox-1/lib/x86/libxul.so
a4840000-a4873000 rw-p 09021000 08:12 393449 /data/app/org.mozilla.firefox-1/lib/x86/libxul.so
We already have logic to fold this type of empty pages but it only works if the previous mappings were executable. In this case they aren't, so the writer will emit two modules for libxul.so. One for the 9b4a0000-9bcae000 range and one for the 9bcae000-a4873000 range. These should be merged together instead.
On Android we frequently find that the linker loads Firefox' libxul.so with holes in it. These corresponds to areas that have been reserved by the linker but weren't actually mapped for some reason. See below for an example of how these mappings look like:
We already have logic to fold this type of empty pages but it only works if the previous mappings were executable. In this case they aren't, so the writer will emit two modules for libxul.so. One for the
9b4a0000-9bcae000range and one for the9bcae000-a4873000range. These should be merged together instead.