summaryrefslogtreecommitdiff
path: root/libc/malloc_hooks/malloc_hooks.cpp
diff options
context:
space:
mode:
authorElliott Hughes <enh@google.com>2021-01-19 09:41:23 -0800
committerElliott Hughes <enh@google.com>2021-01-19 09:47:50 -0800
commit01be44d2f8aa037bd5e8fcf1d7f04ce4caede3fe (patch)
tree522feaafaf690ef4644741eb47201d568f07c853 /libc/malloc_hooks/malloc_hooks.cpp
parent9f72aae9e33f2a2b30de0b666c164d3ce1edb9f3 (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