Depends on D47744
Details
- Reviewers
ruiu peter.smith Bigcheese echristo grimar • espindola alexander-shaposhnikov - Commits
- rGa327a4c34e3c: ELF: Implement --icf=safe using address-significance tables.
rLLD337429: ELF: Implement --icf=safe using address-significance tables.
rL337429: ELF: Implement --icf=safe using address-significance tables.
Diff Detail
- Build Status
Buildable 19311 Build 19311: arc lint + arc unit
Event Timeline
Overall looking pretty good.
lld/ELF/Driver.cpp | ||
---|---|---|
1213 | nit: can't this return type inferred? This function doesn't depend on anything in the outer function. I'd define this as a file-scope function. | |
1224 | Can you add a comment? | |
1236 | toString(F) is better because it automatically include an archive file name if F is created from an archive file. | |
lld/ELF/ICF.cpp | ||
175–176 | Update this comment? | |
lld/ELF/InputFiles.cpp | ||
434 | Maybe this needs some explanation as to why objcopy could break your object files. |
Thanks for the patches. Out of curiosity did you have any thoughts about how the proposal to ELF was going? https://groups.google.com/forum/#!topic/generic-abi/MPr8TVtnVn4 . In particular compressed SHT_SYMATTR seemed promising.
lld/ELF/ICF.cpp | ||
---|---|---|
180 | If I've read this right, we merge read-only sections when ICFLevel::Safe but not when ICFLevel::All? This seems a bit non-intuitive based on the expectation that All will be more aggressive than Safe. On the assumption that the address significance tables permit this to be done safely then would it make sense to do:
| |
lld/ELF/InputFiles.cpp | ||
436 | In the discussions on llvm-dev http://lists.llvm.org/pipermail/llvm-dev/2018-May/123514.html there was some concern that just checking for non preservation of the sh_link field wouldn't catch cases from other ELF processing tools that might preserve sh_link but not the symbol table ordering. I don't think it is necessary to get this in at first, but it may be worth making sure we can add one later without breaking existing object files. Do you have any plans for a stronger check? | |
lld/test/ELF/icf-safe.s | ||
2 | Some ideas for some more tests. I don't think that they are necessary for the patch but are areas that are at higher risk of getting broken by future changes:
|
It does seem promising indeed, and as I mentioned on the thread I think I'd be in favour of that for standardisation, but I think that we should stick with a simple representation to start with since a full implementation of SHT_SYMATTR is beneficial only if it ends up being standardised (and then used for something else), and there's still no concensus as far as I can tell on what (if anything) we're going to do in the gABI.
lld/ELF/ICF.cpp | ||
---|---|---|
180 |
Correct.
I think that's exactly what the end state should be. I was going to do that in a followup since it would involve some rethinking of how KeepUnique and the --keep-unique flag interact. | |
lld/ELF/InputFiles.cpp | ||
436 | It should be possible to add one later. I think your proposal was to compute a hash of the .symtab and .strtab sections, and we can avoid changing the format by storing it in sh_info. | |
lld/test/ELF/icf-safe.s | ||
2 | Will do. |
You'll want to wait on Rui for an actual LGTM, but this looks good to me and will match the llvm support so we can try this out in more detail and see where we should move the proposals.
nit: can't this return type inferred?
This function doesn't depend on anything in the outer function. I'd define this as a file-scope function.