[all-commits] [llvm/llvm-project] 38c356: Fix include guard and properly order __deregister_...

[Sterling-Augustine via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 38c356176b5370164578c1d08e984964354b7189
      https://github.com/llvm/llvm-project/commit/38c356176b5370164578c1d08e984964354b7189
  Author: Sterling Augustine <saugustine at google.com>
  Date:   2019-11-12 (Tue, 12 Nov 2019)

  Changed paths:
    M compiler-rt/CMakeLists.txt
    M compiler-rt/lib/crt/CMakeLists.txt
    M compiler-rt/lib/crt/crtbegin.c
    M compiler-rt/test/crt/ctor_dtor.c

  Log Message:
  -----------
  Fix include guard and properly order __deregister_frame_info.

Summary:
This patch fixes two problems with the crtbegin.c as written:

1. In do_init, register_frame_info is not guarded by a #define, but in
do_fini, deregister_frame_info is guarded by #ifndef
CRT_HAS_INITFINI_ARRAY. Thus when CRT_HAS_INITFINI_ARRAY is not
defined, frames are registered but then never deregistered.

The frame registry mechanism builds a linked-list from the .so's
static variable do_init.object, and when the .so is unloaded, this
memory becomes invalid and should be deregistered.

Further, libgcc's crtbegin treats the frame registry as independent
from the initfini array mechanism.

This patch fixes this by adding a new #define,
"EH_USE_FRAME_INFO_REGISTRY", which is set by the cmake option
COMPILER_RT_CRT_USE_EH_FRAME_REGISTRY Currently, do_init calls
register_frame_info, and then calls the binary's constructors. This
allows constructors to safely use libunwind. However, do_fini calls
deregister_frame_info and then calls the binary's destructors. This
prevents destructors from safely using libunwind.

This patch also switches that ordering, so that destructors can safely
use libunwind. As it happens, this is a fairly common scenario for
thread sanitizer.