- User Since
- Jan 4 2019, 12:51 PM (119 w, 1 d)
Aug 21 2019
Rebased and updated the test.
Could this be due to merge conflict in the test case?
Aug 20 2019
Thanks for reviewing! Updated diff per comments. I don't have commit access though.
Aug 13 2019
Rui, when you get a chance, could you re-review this? Thanks!
Aug 9 2019
Any other things that any of you would like me to address? If not, can we get this reviewed?
Aug 7 2019
Changed to grouping only when addend==0. I did have to move the grouped non-relative relocations to before the relative relocations, so that we can simplify addend encoding.
Aug 6 2019
Expanded test/ELF/pack-dyn-relocs.s to exercise grouping of non-relative relocations as well as grouping by addend when using RELA.
Aug 5 2019
Ping. Rui, could you re-review this and see if everything looks okay to you? Thanks!
Jul 30 2019
Jul 29 2019
Updated to group non-relative relocations by addend, in addition to r_info.
Updated comments in code to better explain what's going on, as per requested by ruiu.
Jul 24 2019
Feb 4 2019
Jan 18 2019
Jan 17 2019
Another data point: Sorting the data section for Chrome on Android, data section dirty pages went down from 6308KB to 6280KB (arm32).
Jan 16 2019
I was able to build and test Chrome on Android. Without this, the dirty pages from all libraries included in Chrome APK sum up to 364KB. With the symbols in those libraries sorted, this comes down to 360KB.
Jan 13 2019
Jan 9 2019
I didn't test the descending order, but assuming there's no special alignment requirement, you'd likely end up with similar result because you are essentially shifting all page boundaries and flipping individual symbols at the same time.
Jan 4 2019
The numbers are measured across all processes running, so there are multiple programs. If you are looking for numbers from a single binary, I saw private dirty from .bss in libc went down from 36KB to 16KB. Unfortunately I didn't record the saving from sorting .bss+.data in libc. I can do the test again if that's necessary.
I'm tempted to sort all SHF_WRITE sections by size by default. Unlike some other sections such as .init_array, there should not be really any program that have an assumption on how .data sections are laid out, but I'm not sure if that wouldn't surprise users. But maybe, we should do that?
Unless there's a certain logic in how things in SHF_WRITE sections are ordered right now, I don't think anyone can realistically depend on the ordering, so this should be safe.