On Wed, Nov 27, 2013 at 4:20 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Wed, Nov 27, 2013 at 04:12:33PM +0400, Alexey Samsonov wrote: >> > Sure, worst case you keep it untested in your LLVM copy of libsanitizer >> > and we'll just need to fix it up during merges if something breaks. >> > If it will be used for GCC (and we have a P1 bug so it is a release blocker >> > if llvm-symbolizer is still used), then it will be tested there. >> >> Yes, I think that's what we should do in the short term. >> I've submitted (slightly edited) version of your patch to compiler-rt >> as r195837, I think > > Thanks, once Kostya merges it in, I'll rework a patch for it (which > hopefully will not need to change anything in the sanitizer_common/ > stuff, just Makefiles/configure and other stuff owned by GCC). > >> it should work after the next merge to gcc. I've done a minimal >> testing of this change >> (built the runtime with -DSANITIZER_LIBBACKTRACE, headers provided, >> libbacktrace.a linked), >> and it "kind of" worked - libbacktrace functions were properly picked >> up, error callbacks was not called, >> but the symbolization didn't work either: >> >> Turns out libbacktrace doesn't work with executables produced by LLVM: >> emitted compile unit DIEs don't have neither >> "DW_AT_low_pc/DW_AT_high_pc" pair, nor DW_AT_ranges reference. > > I'd call that a LLVM bug, not emitting those attributes on a CU sounds like > a flaw in it.
LLVM emits just a DW_AT_low_pc ("base address" of a compilation unit). The standard tells that compilation unit entries "may have" attributes specifying the address range, but doesn't tell they are obligatory. DWARF consumers probably shouldn't rely on their presence. -- Alexey Samsonov, MSK