search for: form_ref4

...his case. Here's what I get: - On OS X, with the "small" test cases I created, I get no errors at all. - On OS X, with my normal unit tests (with the standard library) I get hundreds of error messages of the following form: 0x00000882: DIE attribute 0x00000883: AT_type/FORM_ref4 has a value 0x00000592 that is not in the current compile unit in the .debug_info section. 0x000009a9: DIE attribute 0x000009ae: AT_type/FORM_ref4 has a value 0x000001c2 that is not in the current compile unit in the .debug_info section. 0x00000b85: DIE attribute 0x00000b8a: AT_type/FORM_...

...his case. Here's what I get: > On OS X, with the "small" test cases I created, I get no errors at all. > On OS X, with my normal unit tests (with the standard library) I get hundreds of error messages of the following form: > 0x00000882: DIE attribute 0x00000883: AT_type/FORM_ref4 has a value 0x00000592 that is not in the current compile unit in the .debug_info section. This indicates that while DwarfDebug.cpp was preparing dwarf info, it created a DIE 0x00000592 that was referred by another DIE 0x00000883 but somehow DIE 0x00000592 was not emitted. This could be a bug in...

...; > - On OS X, with the "small" test cases I created, I get no errors at > all. > - On OS X, with my normal unit tests (with the standard library) I get > hundreds of error messages of the following form: > > 0x00000882: DIE attribute 0x00000883: AT_type/FORM_ref4 has a value > 0x00000592 that is not in the current compile unit in the .debug_info > section. > > > This indicates that while DwarfDebug.cpp was preparing dwarf info, it > created a DIE 0x00000592 that was referred by another DIE 0x00000883 but > somehow DIE 0x00000592 was no...

...with the "small" test cases I created, I get no errors at >> all. >> - On OS X, with my normal unit tests (with the standard library) I get >> hundreds of error messages of the following form: >> >> 0x00000882: DIE attribute 0x00000883: AT_type/FORM_ref4 has a value >> 0x00000592 that is not in the current compile unit in the .debug_info >> section. >> >> >> This indicates that while DwarfDebug.cpp was preparing dwarf info, it >> created a DIE 0x00000592 that was referred by another DIE 0x00000883 but >> s...

...; > - On OS X, with the "small" test cases I created, I get no errors at > all. > - On OS X, with my normal unit tests (with the standard library) I get > hundreds of error messages of the following form: > > 0x00000882: DIE attribute 0x00000883: AT_type/FORM_ref4 has a value > 0x00000592 that is not in the current compile unit in the .debug_info > section. > > > This indicates that while DwarfDebug.cpp was preparing dwarf info, it > created a DIE 0x00000592 that was referred by another DIE 0x00000883 but > somehow DIE 0x00000592 was no...

On Apr 7, 2011, at 12:14 PM, Talin wrote: > > OK I've been checking this out some more, and the DIEs don't look valid to me. Take a look at this output from dwarfdump -v: > > 0x000000c7: TAG_subprogram [3] > 0x000000c8: AT_name( .debug_str[0x000001bd] = "construct" ) > 0x000000cc: AT_MIPS_linkage_name( .debug_str[0x000001c7] =

...we don't want to do is process the // concrete DIE twice. if (DIE *AbsSPDIE = AbstractSPDies.lookup(SPNode)) { // Pick up abstract subprogram DIE. SPDie = new DIE(dwarf::DW_TAG_subprogram); SPCU->addDIEEntry(SPDie, dwarf::DW_AT_abstract_origin, dwarf::DW_FORM_ref4, AbsSPDIE); SPCU->addDie(SPDie); } … } The compile unit DIE where AbsSPDIE belongs to is different from the compile unit DIE SPCU->getCUDie(). So it is not legal to use a FORM_ref4 here. Why do we create these subprogram DIEs here? They are added to SPCU, but not inserted via insertDI...

Bunch of initially unrelated context: * type units can be referenced in a variety of ways: * DW_FORM_ref_sig8 on any attribute needing to reference the type * DW_AT_signature on a declaration of the type * extra wrinkle: the declaration can be nested into the appropriate namespace and given a name, or not * LLVM always does the "most expressive"/expensive thing: a full

17.09.2019 3:12, David Blaikie пишет: > > > On Wed, Sep 11, 2019 at 3:32 PM Alexey Lapshin via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Debuginfo and linker folks, we (AccessSoftek) would like to > suggest a proposal for removing obsolete debug info. If you find > it useful we will be happy to work on

...gt; > $ clang++ a.cpp b.cpp -emit-llvm -S -c -g > $ llvm-link a.ll b.ll -o ab.bc > $ clang++ ab.bc -c > $ llvm-dwarfdump ab.o -v -debug-info | > 0x0b: DW_TAG_compile_unit >         DW_AT_name "a.cpp" > 0x2a:   DW_TAG_subprogram >           DW_AT_abstract_origin [DW_FORM_ref4] (cu + 0x0056 => > {0x00000056} "_Z2f1v") >         DW_TAG_subprogram >           DW_AT_name "f1" > 0x6e: DW_TAG_compile_unit >         DW_AT_name "b.cpp" > 0x8d:   DW_TAG_subprogram >           DW_AT_name "main" > 0xa6:     DW_TAG...