Currently the way some relocation-related static functions pass around
states is clumsy. Add a Resolver class to store some states as member
variables.
Advantages:
- Avoid the parameter InputSectionBase &sec (this offsets the cost passing around this paramemter)
- Avoid the parameter end (Mips and PowerPC hacks)
- config and target can be cached as member variables to reduce global state accesses. (potential speedup because the compiler didn't know config/target were not changed across function calls)
- If we ever want to reduce if-else costs (e.g. config->emachine==EM_MIPS for non-Mips) or introduce parallel relocation scan not handling some tricky arches (PPC/Mips)[1], we can templatize Resolver
target isn't used as much as config, so I change it to a const reference
during the migration.
There is a minor performance inprovement for elf::scanRelocations.
[1]: https://maskray.me/blog/2021-12-19-why-isnt-ld.lld-faster "Scan relocations"
I normally think of resolving a relocation when the final value is written. Given that the only public member function is called scanRelocs. Perhaps call the class Scanner or RelocationScanner the latter is more verbose but we could use scan instead of scanRelocs.
Regardless of what the name is, it will be good to have a comment to describe this large class.