diff options
author | Elliott Hughes <enh@google.com> | 2021-01-19 09:41:23 -0800 |
---|---|---|
committer | Elliott Hughes <enh@google.com> | 2021-01-19 09:47:50 -0800 |
commit | 01be44d2f8aa037bd5e8fcf1d7f04ce4caede3fe (patch) | |
tree | 522feaafaf690ef4644741eb47201d568f07c853 /libc/malloc_hooks/malloc_hooks.cpp | |
parent | 9f72aae9e33f2a2b30de0b666c164d3ce1edb9f3 (diff) |
Inline call_array for clearer stack traces.
No-one seems to understand that a crash in a random .so from call_array()
in the linker isn't a linker bug. They _seem_ to understand (or at least
claim to) when we explain that this is just the linker calling their ELF
constructors --- despite the fact that the caller of call_array() is
call_constructors().
One experiment we can try though is to inline call_array() to elide that
frame from the crash dumps. I do also wonder whether renaming
call_constructors() to call_elf_constructors() would help/hinder/make no
difference. For now I'm leaning toward "hinder" because I suspect most
people don't understand "ELF constructor" and C++ folks at least will
probably be influenced in a not wholly incorrect direction when they
hear "constructor" (whereas "ELF constructor" might mislead them back in
the direction of "strange linker magic, not my fault" again)...
(The reformatting is clang-format's decision, not mine.)
Test: treehugger
Change-Id: I65ab95ceb2e988fd053c48c66f51afba17ccfa61
Diffstat (limited to 'libc/malloc_hooks/malloc_hooks.cpp')
0 files changed, 0 insertions, 0 deletions