search for: dwarf4

Hi, I've built the llvm-dwarfdump tool from the 3.3 branch and ran it on simple binary compiled with dwarf4 debug information. The tool seem to read the file correctly including dwarf information (DIContext::getDWARFContext returns a valid context), but when trying to access line information, all I get is "<invalid>" string for the file name and 0's for line and column information....

> I've built the llvm-dwarfdump tool from the 3.3 branch and ran it on simple > binary compiled with dwarf4 debug information. > > > > The tool seem to read the file correctly including dwarf information > (DIContext::getDWARFContext returns a valid context), but when trying to > access line information, all I get is "<invalid>" string for the file name > and 0's...

...solutions looks to be to deduplicate 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...

...solutions looks to be to deduplicate 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...

On 2020-11-14, Alexander Yermolovich wrote: >Thanks for doing a diff and asking in other groups. > >So if I understand your concern with using first reloc as it relates to .debug_str. > >In DWARF4 for .debug_str is referenced from .debug_info, .debug_type using DW_FORM_strp. For DWARF32 it's 32bit unsigned, for DWARF64 it's 64bit unsigned. So in relocation section for some .debug_info section we will have a relocation entry to patch up DW_FORM_strp. Either R_X86_64_32, or R_X86_64_64...

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 first DWORD of ....

...o 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...

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

...,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.

...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-generic/dwarfex...

...[LLD] Support DWARF64, debug_info "sorting" > > On 2020-11-14, Alexander Yermolovich wrote: > >Thanks for doing a diff and asking in other groups. > > > >So if I understand your concern with using first reloc as it relates to > .debug_str. > > > >In DWARF4 for .debug_str is referenced from .debug_info, .debug_type > using DW_FORM_strp. For DWARF32 it's 32bit unsigned, for DWARF64 it's > 64bit unsigned. So in relocation section for some .debug_info section we > will have a relocation entry to patch up DW_FORM_strp. Either R_X86_64_32,...

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:

...is someone could point me to some >> documentation which explains at a high-level how llvm-symboliser >> works. Reading the source code was too difficult for me as I am not >> very experienced with C++ programming. >> I suspect all the usual resources apply — resources on DWARF4, and potentially looking at the various encodings. I’m not a DWARF expert, but David Blaikie might be able to help more specifically on emitting useful DWARF information via LLVM. >> Many thanks for your help, >> Apologies for the delay again. Cheers -- Dean

...ormation avoid perturbing code gen is one of those "thou shalt avoid" commandments :) That said in the case he's talking about it's basically treating the incoming argument as another variable so having it list as not in a range is somewhat acceptable. There's some support in dwarf4 for trying to keep track of what a variable would be had a computation not been deleted (i.e. useless). Not quite what we're talking about here since the variable has basically ceased to exist. Also, a lot of debuggers will keep track of incoming values at function start. Unless something is c...

...in the same ballpark as the already done section > compressing (see table 2 point F)). > > > I believe #1 was added to DWARF5 to make link-time debug info GC > possible, so could you tell me a little bit about why you chose to do > #3? Is this because you want to do this for DWARF4? > > No, that proposal is not DWARF-4 specific. The proposal is for DWARF-5 also.  The solution added to DWARF-5("E.3.3 Single-function-per-DWARF-compilation-unit" page 388.) is not a complete solution. This is a recommendation which needs to have an additional specification. Th...

...t where values that couldn't be placed in callee-saved registers (and that were allocated to caller-saved registers) were spilled to the stack as part of the function call procedure. Hopefully this clarifies things -- thanks! [1] http://llvm.org/docs/StackMaps.html [2] http://dwarfstd.org/doc/DWARF4.pdf, page 140 On Mon, Jun 27, 2016 at 10:28 AM, Rob Lyerly <rlyerly at vt.edu> wrote: > Hi Sanjoy, > > I'm having trouble finding caller-saved registers using the RegMask > operand you've mentioned. As an example, I've got a C function that looks > like this: &gt...

...documentation which explains at a high-level how llvm-symboliser >> >> works. Reading the source code was too difficult for me as I am not >> >> very experienced with C++ programming. >> >> >> >> I suspect all the usual resources apply — resources on DWARF4, and potentially looking at the various encodings. I’m not a DWARF expert, but >> David Blaikie might be able to help more specifically on emitting useful DWARF information via LLVM. >> >> >> Many thanks for your help, >> >> >> >> Apologies for the de...

...Full declarations with type and a slimmed down version with an abstract origin. How will we reference types in the DWARF blob? * ODR types can be referenced by name * Non-odr types by full DWARF hash * Each type can be a pair(tuple) of identifier (DITypeRef today) and blob. * For < DWARF4 we can emit each type as a unit, but not a DWARF Type Unit and use references and module relocations for the offsets. (See below) How will we handle references in DWARF2 or global relocations for non-type template parameters? * We can use a “relocation” metadata as part of the format. * Repr...

...t second part seems pretty expensive compared to anything else the linker is doing with debug info. I'd try to avoid it if at all possible. > As the result all address ranges pointing into dead code would be marked > as zero length. > > There still exist another problem: > > DWARF4: "A range list entry (but not a base address selection or end of > list entry) whose beginning and > ending addresses are equal has no effect because the size of the range > covered by such an > entry is zero." > > DWARF5: "A bounded range entry whose beginning and...

Thanks for doing a diff and asking in other groups. So if I understand your concern with using first reloc as it relates to .debug_str. In DWARF4 for .debug_str is referenced from .debug_info, .debug_type using DW_FORM_strp. For DWARF32 it's 32bit unsigned, for DWARF64 it's 64bit unsigned. So in relocation section for some .debug_info section we will have a relocation entry to patch up DW_FORM_strp. Either R_X86_64_32, or R_X86_64_64...