[coarse][persist] app code relocations for persisted cache

_From [bruen...@google.com](https://code.google.com/u/109494838902877177630/) on January 28, 2012 15:22:15_

this was PR 214016

for applying app relocs to a persisted DR cache (PR 208785/4307), have two choices:

1) at freeze time (PR 213091/8656) when we're calculating size of each fragment,
build up a reloc data structure for the frozen unit

2) at persisted load time, use the original app .reloc section and walk the
fragments, calculating sizes and apply relocs

in either case, may want to transform .reloc into a sub-linear-searchable
data struct; or else first walk and record all the sizes and then walk
.reloc

note that we need to store relocation data for our own call manglings
(PR 214084) in either case

xref PR 214404: [persist] data structure for mapping app pc to persisted cache offset: relocations, avoiding hotpatch flushes
where we may want at least real instruction boundaries, while
reusing the data that would be needed for 2) above

probably best to do 1) and add to that all addresses we have mangled in our
calls (so that does also bug 214084) while bug 214404 can do with less
than a heavy weight version of 2)

I'm seriously considering auto-PIC-ify (PR 221544) as an alternative to
up-front relocation. We should compare performance of the two: for
long-running applications, up-front should win, but for startup performance
PIC very well could be the way to go.

for libraries that are PIC we can avoid relocations.

_Original issue: http://code.google.com/p/dynamorio/issues/detail?id=661_

No files or tests are named. Start by reviewing the referenced persisted-cache and relocation work in PRs 213091/8656, 214084, 214404, and 221544, then compare the proposed freeze-time relocation approach with auto-PIC for startup and long-running performance. Done requires a decided approach that accounts for mangled calls and library PIC behavior.

Written by the indexing model from the issue text.