drsyms sideline symbol server

_From [bruen...@google.com](https://code.google.com/u/109494838902877177630/) on May 06, 2011 11:42:05_

split from issue #44 see all the comments in that issue regarding sideline support
this issue covers a sideline implementation on both linux and windows

sideline is needed in cases where symbols don't fit into the app's process
(see https://code.google.com/p/dynamorio/issues/detail?id=44#c11 )

my drsyms API assumes sideline will use the same synchronous interface as
online, and uses shared memory, with a shmid passed to drsym_init(), so the
sideline server must be launched ahead of time.
we can revisit that decision but if we want to provide an asynchronous
model I would suggest adding another set of interfaces for that and keeping
the synchronous ones working with sideline.

here are some notes from earlier discussions including proposals of having
the sym server queries have tunable timeouts:

Shared memory is definitely the best choice for Linux and Windows. For
Windows the keys are strings. See api/samples/stats.c for code using
syscall/ntdll layer (for DR), and tools/DRgui/DynamoRIOView.cpp for code
using Win32 API (for symbol server).

I would vote for what you listed under Optimization:
- Have a simple platform-independent symbol table format that ignores
scopes and other complexities (unless you have a use case that requires
scopes?)
- The client symbol query API is also very simple (unless we have use cases
that need more):
- look up symbol name from address
- look up address from symbol name
- look up func+file+line# from address

The client query API is abstracted away from the underlying symbol table
format, which is not exposed, so that we can change the format later and
add scopes, etc. if we need them.
- On a module load, DR requests that the symbol server provide a symbol
table for that module. That request is asynchronous by default, and if
the client makes a query before the information is ready the query simply
fails. We provide a runtime option that makes DR block until the symbol
info is ready on a module load for clients that need that and don't want
to delay/retry their queries.

Then we don't have any client queries going to the symbol server: DR
answers them synchronously from its platform-independent symbol tables, and
only DR's entire-module queries go to the symbol server.

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

Read issue #44 and the referenced api/samples/stats.c and tools/DRgui/DynamoRIOView.cpp examples first. Resolve the Linux and Windows sideline protocol and synchronous versus asynchronous behavior described here; done means a sideline symbol-server implementation works with the drsyms API on both platforms.

Written by the indexing model from the issue text.