There are some cases where cannot infer a shared symbol's alignment.
But a shared symbol's alignment only matters when creating a copy
relocation. This change moves the alignment computation into the code
that creates copy relocations.
Details
- Reviewers
ruiu shenhan • espindola
Diff Detail
- Build Status
Buildable 18843 Build 18843: arc lint + arc unit
Event Timeline
This patch itself looks decent, but I think the principle here is to avoid referring ELF-file data structures directly from Symbol to reduce dependency between Symbol and the underlying ELF files. Previously, we store a pointer to ELFSym to each Symbol, and at some point we rewrote to eliminate that. That makes it easy to create a fake Shared symbol too.
That certainly makes sense for Defined, but maybe not so much for SharedSymbol, at least when we don't have any code which actually creates fake shared symbols. You'll note that there are already dependencies on there being an actual .so file, e.g. with VerdefIndex, and I reckon that it's probably better to depend on the .so fully rather than being in a half dependent state.
That's true that a shared symbol can refer an underlying ELF data structure using VerdefIndex, but that's I believe optional. You can leave it out with the default value to represent "no version". For ELFSym, it is mandatory, and we are not doing that in other places, so I'm inclined to not do this.
There are other cases as well: http://llvm-cs.pcc.me.uk/tools/lld/ELF/Symbols.h/rgetFile
But I guess I don't feel too strongly so I'll abandon this.