Build isolated non-instrumented in-process symbolizer

[ramosian-glider]

Originally reported on Google Code with ID 206

To simplify deployment, we'd like to build symbolizer
(a) in-process, i.e. statically linked to the user program
(b) uninstrumented (this is especially important for MSan)

(b) is especially tricky, because symbolizer uses some LLVM internals, as well as the
C++ standard library, and this code must not be shared with the user application (which
may have an instrumented copy of it). Calling instrumented code from symbolizer is
also a no-no, which means the symbolizer must have a private copy of libstdc++/libc++.

I see two ways of doing this, both not without drawbacks.

Common idea: we build (or otherwise obtain) uninstrumented symbolizer, libstdc++/libc++,
zlib. Then we link them all into a relocatable object (.o), binding all internal references
and hiding them from the final (user) link. The resulting object should export the
symbolizer interface (5 functions or so), and depend on libc and sanitizer runtime
(for internal versions of certain problematic libc functions).

(1) LLVM way. We get the source for everything, including libc++, libc++abi, zlib.

  * Compile them to .bc (LTO-style)
  * llvm-link them together into a single .bc
  * opt -internalize-internalize-public-api-list= to hide everything except the public
interface
  * finally compile .bc -> .o
This should work everywhere with LLVM (i.e. Mac, Windows, etc). Not appropriate for
GCC sanitizers.

(2) Binutils way. No need for zlib source.
  * Compile everything to .o
  * Link with -r -nostdlib to get one big .o
  * objcopy --keep-global-symbols= to localize everythign except the public interface
This is limited to Linux, but will work with GCC.

Reported by [email protected] on 2013-07-01 08:26:05

[ramosian-glider]

I think there are problems with using this for GCC:
* Looks like we'll have to use libsupc++ and libstdc++ sources in the same way we use
libc++, libc++abi for LLVM.
* there is no llvm-symbolizer in GCC :)

Reported by [email protected] on 2013-07-01 08:33:48

[ramosian-glider]

looks like issues 206 and 16 are the same.
We are very close to declaring victory
(https://code.google.com/p/address-sanitizer/wiki/CallStack)
Alexey, please comment on issue 16.
Closing this one as a dup.

Reported by konstantin.s.serebryany on 2013-10-04 10:39:54

• Status changed: Duplicate
• Merged into: symbolize stack traces using code from lldb #16

[ramosian-glider]

Adding Project:AddressSanitizer as part of GitHub migration.

Reported by ramosian.glider on 2015-07-30 09:13:41

• Labels added: ProjectAddressSanitizer