search for: dw_form_

...;> >> This is potentially related to other .debug_* (not .debug_line) >> I hope Chromium developers can chime in here:) The breakage was >> unfortunate but I don't know how we could have avoided that. IMHO this >> is no different from "clang started to emit a new DW_FORM_* and a >> postprocessing tool of .debug chokes on that" Whether we want to >> suppress that particular DW_FORM_* definitely should depend on how >> likely it can cause problems, but we can't yet say we have to hold off >> on a feature for a solved (precisely, mitiga...

In short: Perhaps we should switch lld to the bfd-style tombstoning behavior for a release or two, letting users opt-in to testing with the new -1/-2 tombstoning in the interim, before switching to the new tombstone by default (while still having the flag to switch back when users find surprise places that can't handle the new behavior). In long: https://reviews.llvm.org/D81784 and follow-on

One other thing that may or may not illuminate the situation. When I run under gdb (on OS X 10.8.3 this is an ancient version of gdb 6.3.5 - but it works with clang compiled C++ code) I get the following error when I try to list a line in dwarf1.lsp: Dwarf Error: Cannot handle DW_FORM_<unknown> in DWARF reader [in module /Users/meister/Development/cando/src/tests/core/dwarf1.bundle] (gdb) ---------- full gdb transcript follows ---------- (gdb) run Reading symbols for shared libraries ++++++++++++++++++++++.............................. done Using lisp-source-directory --...

I upgraded my versions of llvm, clang and compiler-rt to the top-of-tree versions from last night (r180162, April 24). I recompiled debug versions of llvm, clang and my code. I then regenerated my test case and the results were the same - I can list lines of dwarf1.lsp in lldb but I can't set break-points or do anything else (what else should I be able to do?). The updated file that

...ally related to other .debug_* (not .debug_line) > > >> I hope Chromium developers can chime in here:) The breakage was > > >> unfortunate but I don't know how we could have avoided that. IMHO this > > >> is no different from "clang started to emit a new DW_FORM_* and a > > >> postprocessing tool of .debug chokes on that" Whether we want to > > >> suppress that particular DW_FORM_* definitely should depend on how > > >> likely it can cause problems, but we can't yet say we have to hold off > > >> on a...

...This is potentially related to other .debug_* (not .debug_line) > >> I hope Chromium developers can chime in here:) The breakage was > >> unfortunate but I don't know how we could have avoided that. IMHO this > >> is no different from "clang started to emit a new DW_FORM_* and a > >> postprocessing tool of .debug chokes on that" Whether we want to > >> suppress that particular DW_FORM_* definitely should depend on how > >> likely it can cause problems, but we can't yet say we have to hold off > >> on a feature for a solve...

....debug_line) > > > > >> I hope Chromium developers can chime in here:) The breakage was > > > > >> unfortunate but I don't know how we could have avoided that. IMHO > this > > > > >> is no different from "clang started to emit a new DW_FORM_* and a > > > > >> postprocessing tool of .debug chokes on that" Whether we want to > > > > >> suppress that particular DW_FORM_* definitely should depend on how > > > > >> likely it can cause problems, but we can't yet say we have to &g...

...gt;> > > > >> I hope Chromium developers can chime in here:) The breakage was >>> > > > >> unfortunate but I don't know how we could have avoided that. IMHO this >>> > > > >> is no different from "clang started to emit a new DW_FORM_* and a >>> > > > >> postprocessing tool of .debug chokes on that" Whether we want to >>> > > > >> suppress that particular DW_FORM_* definitely should depend on how >>> > > > >> likely it can cause problems, but we can'...

...; I hope Chromium developers can chime in here:) The breakage > was > > >>> > > > >> unfortunate but I don't know how we could have avoided > that. IMHO this > > >>> > > > >> is no different from "clang started to emit a new DW_FORM_* > and a > > >>> > > > >> postprocessing tool of .debug chokes on that" Whether we > want to > > >>> > > > >> suppress that particular DW_FORM_* definitely should depend > on how > > >>> > > > >>...

...t; > > >> I hope Chromium developers can chime in here:) The breakage was > >>> > > > >> unfortunate but I don't know how we could have avoided that. IMHO this > >>> > > > >> is no different from "clang started to emit a new DW_FORM_* and a > >>> > > > >> postprocessing tool of .debug chokes on that" Whether we want to > >>> > > > >> suppress that particular DW_FORM_* definitely should depend on how > >>> > > > >> likely it can cause problems,...

...gt; I hope Chromium developers can chime in here:) The breakage was >> > >>> > > > >> unfortunate but I don't know how we could have avoided that. IMHO this >> > >>> > > > >> is no different from "clang started to emit a new DW_FORM_* and a >> > >>> > > > >> postprocessing tool of .debug chokes on that" Whether we want to >> > >>> > > > >> suppress that particular DW_FORM_* definitely should depend on how >> > >>> > > > >> li...

...ere:) The >> breakage was >> >> > >>> > > > >> unfortunate but I don't know how we could have avoided >> that. IMHO this >> >> > >>> > > > >> is no different from "clang started to emit a new >> DW_FORM_* and a >> >> > >>> > > > >> postprocessing tool of .debug chokes on that" Whether we >> want to >> >> > >>> > > > >> suppress that particular DW_FORM_* definitely should >> depend on how >> >>...

...> >> >> > >>> > > > >> unfortunate but I don't know how we could have avoided >> >> that. IMHO this >> >> >> > >>> > > > >> is no different from "clang started to emit a new >> >> DW_FORM_* and a >> >> >> > >>> > > > >> postprocessing tool of .debug chokes on that" Whether we >> >> want to >> >> >> > >>> > > > >> suppress that particular DW_FORM_* definitely should >> >...

...t;>> > > > >> unfortunate but I don't know how we could have avoided > > >> >> that. IMHO this > > >> >> >> > >>> > > > >> is no different from "clang started to emit a new > > >> >> DW_FORM_* and a > > >> >> >> > >>> > > > >> postprocessing tool of .debug chokes on that" Whether we > > >> >> want to > > >> >> >> > >>> > > > >> suppress that particular DW_FORM_* d...

...tunate but I don't know how we could > have avoided > > > > >> >> that. IMHO this > > > > >> >> >> > >>> > > > >> is no different from "clang started to emit > a new > > > > >> >> DW_FORM_* and a > > > > >> >> >> > >>> > > > >> postprocessing tool of .debug chokes on > that" Whether we > > > > >> >> want to > > > > >> >> >> > >>> > > > >> s...

...how we could > have avoided > >> > > > >> >> that. IMHO this > >> > > > >> >> >> > >>> > > > >> is no different from "clang started to > emit a new > >> > > > >> >> DW_FORM_* and a > >> > > > >> >> >> > >>> > > > >> postprocessing tool of .debug chokes on > that" Whether we > >> > > > >> >> want to > >> > > > >> >> >> > >>&gt...