search for: dwarfstd

...Date: Feb 18, 2014 7:58 AM Subject: Deadline for DWARF Version 5 comments -- March 31, 2014 To: "gdb at sourceware.org" <gdb at sourceware.org>, "GCC" <gcc at gcc.gnu.org>, < lldb-dev at cs.uiuc.edu> Cc: The DWARF Debugging Information Format Committee (http://dwarfstd.org) is nearing completion on the DWARF Version 5 standard. We anticipate a public comment draft to be released mid-2014. As in the past, we have attempted where possible to make DWARF Version 5 backward compatible with previous versions. We will be accepting public comments, suggestions, or pro...

...ate information to reduce .debug_info size. The rest of mail contains information about experiments I did, the obtained results and some questions and suggestions as well. I was investigating idea to deduplicate debug types information. Idea is described at p276 of DWARF4 specification (http://www.dwarfstd.org/doc/DWARF4.pdf). It suggests to split types information out of .debug_info and emit multiple .debug_types sections with use of COMDATs. Both clang and gcc I tested implements -fdebug-types-section flag for that: -fdebug-types-section, -fno-debug-types-section Place debug types in their own sec...

Hello all, There is one enhancement request open for dwarfv5, http://dwarfstd.org/ShowIssue.php?issue=191107.1 The request is for addition of dwarf expression operator to swap the top of the dwarf stack, the response seems positive but it may take some time till v6. I like to add that operator as vendor extension but I am not sure how to go about it for llvm/lldb. Currently...

On 04/26/2013 19:50, Jiong Wang wrote: > > > why do you want to prevent R_X86_64_32 generation? for 32bit dwarf, > I think generation of R_X86_64_32 is reasonable. > > you can check http://dwarfstd.org/doc/DWARF4.pdf. Because R_X86_64_32 elements are 4-byte addresses and can't be relocated for the 64-bit address space over 32-bit limit. Dwarf2 actually allows for both 32bit and 64-bit relocations. The document, mentioned by you, explains this in section 7.5.1.1 on page 143. If the f...

...ate information to reduce .debug_info size. The rest of mail contains information about experiments I did, the obtained results and some questions and suggestions as well. I was investigating idea to deduplicate debug types information. Idea is described at p276 of DWARF4 specification (http://www.dwarfstd.org/doc/DWARF4.pdf). It suggests to split types information out of .debug_info and emit multiple .debug_types sections with use of COMDATs. Both clang and gcc I tested implements -fdebug-types-section flag for that: -fdebug-types-section, -fno-debug-types-section Place debug types in their own sec...

...the code in lib/CodeGen/AsmPrinter/DwarfDebug.cpp around line > 1035, > this does appear to be the case. > > If you haven't already read the DWARF specification documents, then I recommend looking at them if you're not going to be using DIFactory. You can find them here: http://dwarfstd.org/Download.php thanks, bagel > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- -- Talin -------------- next part -------------- An H...

The AMDIL Target needs new dwarf tokens for dwarf debug support, I'd we should handle this best? (which numbers to use for the new tokens): Two new tokens will be added: DW_AT_AMDIL_address_space (currently 0x3ff1) : needed in order to know which address space to read data from DW_AT_AMDIL_resource (currently 0x3ff2) : the resource ID information for when we read memory from UAV ---Yousef

...ll be added: > > DW_AT_AMDIL_address_space (currently 0x3ff1) : needed in order to know > which address space to read data from > > DW_AT_AMDIL_resource (currently 0x3ff2) : the resource ID information > for when we read memory from UAV Does it make sense to go through http://www.dwarfstd.org/Issues.php first? Or do you expect this to be a long-lived LLVM extension with no intention of becoming standardized? Nick

ELF module of type ET_REL (Relocable module), generated by LLVM, always has some R_X86_64_32 in debug information sections. This happens with Reloc models Default,Static,PIC_ and with CodeModel set to Large. What is the way to prevent R_X86_64_32 ELF from ever appearing in ELF? Yuri

...ls Default,Static,PIC_ and with CodeModel > set to Large. > > What is the way to prevent R_X86_64_32 ELF from ever appearing in ELF? Hi Yuri, why do you want to prevent R_X86_64_32 generation? for 32bit dwarf, I think generation of R_X86_64_32 is reasonable. you can check http://dwarfstd.org/doc/DWARF4.pdf. > > Yuri > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -- Regards, Jiong. Wang Tilera Corporation.

...;> other staff </head> this is the correct style. .\llvm\docs\SourceLevelDebugging.html Chris Lattner sabre at nondot.org Jim Laskey jlaskey at mac.com Philosophy behind LLVM debugging information while don't change the link http://www.eagercon.com/dwarf/dwarf3std.htm to http://www.dwarfstd.org/ and i found the link in http://www.eagercon.com/dwarf/dwarf3std.htmis not accessible. .\llvm\docs\ExtendingLLVM.html Written by Misha Brukman, Brad Jones, Nate Begeman, and Chris Lattner In section Adding a new instruction 4.llvm/lib/AsmParser/Lexer.l: add a new token to parse your instructi...

...org/D54747 7. [ELF] Add --strip-debug-non-line option     https://reviews.llvm.org/D46628 8. Monolithic input section handling         https://groups.google.com/forum/#!msg/generic-abi/A-1rbP8hFCA/EDA7Sf3KBwAJ 9. Using COMDAT Sections to Reduce the Size of DWARF Debug Information     http://wiki.dwarfstd.org/index.php?title=COMDAT_Type_Sections 10. DWARF Extensions for Unwinding Across Merged Functions     http://wiki.dwarfstd.org/index.php?title=ICF 11. Type Unit Merge     http://dwarfstd.org/ShowIssue.php?issue=130526.1 12. DWARF Extensions for Separate Debug Information Files     https://gcc....

...nter, compiling void f(void *); void g(void) { f(alloca(100)); } produces pushq %rbx Ltmp2: .cfi_def_cfa_offset 16 subq $112, %rsp Ltmp3: .cfi_def_cfa_offset 128 Ltmp4: .cfi_offset %rbx, -16 Which does contain the rsp updates. The two places I can think with some documentation are http://www.dwarfstd.org/doc/DWARF4.pdf (the 6.4 Call Frame Information section). This is the old .debug_frame, but that is where the idea came from. http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-...

Hi Reed I think what you need is DWARF location lists. See 2.6.4 here http://www.dwarfstd.org/doc/040408.1.html I think you'd need to mark the values as being in a register location from the function start address, then at the point where they are saved to the stack add a new location to the list for the stack location. Unfortunately i don't know if we support this or how to g...

Hi Rafael, I've been staring at the CFI directives and have a question. Some background: I want to generate the compact unwind information using just the CFI directives. I *think* that this should be doable. The issue I'm facing right now is that I need to know how much the stack pointer was adjusted. So when I have something like this: .cfi_startproc Lfunc_begin175:

Hi DebugInfo folks, I have a question on using fsplit-dwarf-inlining option: "-fsplit-dwarf-inlining, -fno-split-dwarf-inlining Provide minimal debug info in the object/executable to facilitate online symbolication/stack traces in the absence of .dwo/.dwp files when using Split DWARF" i.e. it puts some debug info into compilation unit from First partition(with Skeleton unit). At

On 12/06/2010 12:03 PM, Devang Patel wrote: > As I understand, you are not interested in 'how to use DIFactory'. Do you want > to know what are the fields of metadata to encode debug info for a local variable ? > That'd be > > !7 = metadata !{ > i32, ;; Tag (see below) > metadata, ;; Context > metadata, ;; Name > metadata, ;; Reference to

On Mips, we have argument registers which are treated as scratch registers with a live in. This will not work with -g -O0 because the arguments to the function will not be displayable after they are clobbered. I'm guess others have solved this problem. Is there a preferred way? Reed

...eady in LLVM/LLDB, though I guess the main question would be: what's the motivation? On Mon, Dec 2, 2019 at 3:14 AM Chirag Patel via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hello all, There is one enhancement request open for dwarfv5, http://dwarfstd.org/ShowIssue.php?issue=191107.1 The request is for addition of dwarf expression operator to swap the top of the dwarf stack, the response seems positive but it may take some time till v6. I like to add that operator as vendor extension but I am not sure how to go about it for llvm/lldb. Currently...

...l contains information about experiments I did, the > > obtained results and > > some questions and suggestions as well. > > > > I was investigating idea to deduplicate debug types information. Idea is > > described at > > p276 of DWARF4 specification (http://www.dwarfstd.org/doc/DWARF4.pdf). > It > > suggests > > to split types information out of .debug_info and emit multiple > > .debug_types sections > > with use of COMDATs. Both clang and gcc I tested implements > > -fdebug-types-section flag for that: > > > > -fdebug-...