search for: debug_str

Currently llvm-dwarfdump isn't very useful on ELF .o files because it doesn't apply relocations. nlewycky at ducttape:~$ llvm-dwarfdump helloworld.o | grep debug_str\\[ 0x0000000c: DW_AT_producer [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 3.2 (trunk 163034)") 0x00000012: DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 3.2 (trunk 163034)") 0x00000022: DW_AT_comp_dir [DW_FORM_strp] ( .debug_str[0...

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

...gt; > Subject: Re: [llvm-dev] [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_...

...-------------------------------------------------- > .debug_info contents: > > 0x00000000: Compile Unit: length = 0x0000005b version = 0x0004 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x0000005f) > > 0x0000000b: TAG_compile_unit [1] * > 0x0000000c: AT_producer( .debug_str[0x00000000] = "clang version 3.5.0 (209308)" ) > 0x00000010: AT_language( 0x0004 ( DW_LANG_C_plus_plus ) ) > 0x00000012: AT_name( .debug_str[0x0000001d] = "test.cc <http://test.cc/>" ) > 0x00000016: AT_stmt_list( 0x00000000 ( 0x00000000 ) ) > 0x0000001a: AT...

On 18.11.2020 0:20, Robinson, Paul wrote: > This is a problem only if the .debug_str section *by itself* exceeds 4GB; > are we anticipating that will happen IRL? The section is just a string > section, by itself it has no 32/64 format. > > If the .debug_str section *by itself* exceeds 4GB, then yes any string > with a 32-bit reference to it must be in the first 4GB...

Hey guys, Frederic is introducing the expression dumping support and in the interests of tersity is skipping the "DW_" in every "DW_OP" (heck, we could even skip the "OP" given the context - nothing else textual can appear there, right?) Any thoughts on skipping the "DW_" (maybe even the AT/TAG/FORM too) in the rest of dwarfdump? (skipping the AT/TAG (FORM

On 19.11.2020 03:21, Cary Coutant wrote: >>> If the .debug_str section *by itself* exceeds 4GB, then yes any string >>> with a 32-bit reference to it must be in the first 4GB. Strings that >>> have only 64-bit references to them can be sorted to the end of the >>> section, if necessary. I wouldn't think anyone guarantees or car...

...-------------------------- >> .debug_info contents: >> >> 0x00000000: Compile Unit: length = 0x0000005b version = 0x0004 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x0000005f) >> >> 0x0000000b: TAG_compile_unit [1] * >> 0x0000000c: AT_producer( .debug_str[0x00000000] = "clang version 3.5.0 (209308)" ) >> 0x00000010: AT_language( 0x0004 ( DW_LANG_C_plus_plus ) ) >> 0x00000012: AT_name( .debug_str[0x0000001d] = "test.cc <http://test.cc/>" ) >> 0x00000016: AT_stmt_list( 0x00000000 ( 0x00000000 ) ) >>...

...2 offset 1849950870 > My module is a DLL built with llc+ld toolchain. Target triple: 'i686-w64-mingw32'. Looking this offset (1849950870 == 0x6e440296) in dwarfdump output of the dll gave the following: 0x00000296: DW_TAG_base_type [10] DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000068f] = "void") DW_AT_encoding [DW_FORM_data1] (0x00) DW_AT_byte_size [DW_FORM_data1] (0x00) .... 0x00000cf8: DW_TAG_subprogram [16] * DW_AT_low_pc [DW_FORM_addr] (0x000000006e384c30) DW_AT_high_pc [DW_FORM_d...

...section .debug_aranges,"", at progbits > .section .debug_macinfo,"", at progbits > .section .debug_line,"", at progbits > Lsection_line: > .section .debug_loc,"", at progbits > .section .debug_pubtypes,"", at progbits > .section .debug_str,"MS", at progbits,1 > Linfo_string: > .section .debug_ranges,"", at progbits > Ldebug_range: > .section .debug_loc,"", at progbits > Lsection_debug_loc: > .text > Ltext_begin: > .data > .file 1 "test.c" > .text > .global main...

...looked in to the generated debug dump from the object file I >> > > found that DW_AT_name is always (indirect string, offset: 0x0): clang >> > > version 8.0.1, instead of variable names. >> > >> > That symptom suggests that relocations from .debug_info to .debug_str >> > are not being handled correctly. Either your backend is not emitting >> > them correctly, or the dumper does not know what to do with them. >> > >> > If you are able to dump the .rela.debug_info section and it looks >> > reasonable, the fault is mo...

...(x86_64) ---------------------------------------------------------------------- .debug_info contents: 0x00000000: Compile Unit: length = 0x0000005b version = 0x0004 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x0000005f) 0x0000000b: TAG_compile_unit [1] * 0x0000000c: AT_producer( .debug_str[0x00000000] = "clang version 3.5.0 (209308)" ) 0x00000010: AT_language( 0x0004 ( DW_LANG_C_plus_plus ) ) 0x00000012: AT_name( .debug_str[0x0000001d] = "test.cc<http://test.cc/>" ) 0x00000016: AT_stmt_list( 0x00000000 ( 0x00000000 ) ) 0x0000001a: AT_comp_dir( .debug_str...

Since updating today I get: section name .debug_str is longer than 8 characters and will use a non-standard string table This is LLD + Coff/DWARF; Is this now unsupported, am I doing something wrong or something else?Alternatively, what can I do to hide it?

...in my reply there > > > > https://sourceware.org/pipermail/binutils/2020-November/114125.html > > > > > > > > (a) My prototype has made me feel uneasy with this approach. > > > > > > > > <quote> > > > > In DWARF v4 or if .debug_str_offset is not used, it is a problem. A > > > > heuristic is: if an input section in a file is marked DWARF64, we mark > > > > all other .debug_* DWARF64. This makes me feel a bit uneasy because > > > > for an output section description > > > > > &g...

...36084> (sandybridge): > llvm-exegesis -opcode-name IMUL16rri8 -benchmark-mode latency --- asm_template: name: latency IMUL16rri8 cpu_name: sandybridge llvm_triple: x86_64-grtev4-linux-gnu num_repetitions: 10000 measurements: - { key: latency, value: 4.0115, debug_string: '' } error: '' ... > llvm-exegesis -opcode-name IMUL16rri8 -benchmark-mode uops --- asm_template: name: uops IMUL16rri8 cpu_name: sandybridge llvm_triple: x86_64-grtev4-linux-gnu num_repetitions: 10000 measurements: - { key: '2...

All of this information is contained in the DWARF debug info that you must generate. Are you generating DWARF? If not, you will need to. If so, please attach an example program that contains DWARF and specify which function you are having trouble getting variable information for. Greg Clayton On Feb 18, 2014, at 12:44 AM, 杨勇勇 <triple.yang at gmail.com> wrote: > Hi, all > > I

?Hi ! I have a question about code used for collecting ranges. I was trying to fix PR35199. Its issue that it calls unreachable when calls DWARFObject::getFileName(). We do not implement this method in LLD and it fails. Issue appears when we start to provide .debug_str section to DWARF parser. And it is relative to following code (lines 335-339): https://github.com/llvm-mirror/llvm/blob/master/lib/DebugInfo/DWARF/DWARFUnit.cpp#L335 Object I used for debugging parser is following: t.ii: int a; clang++ -gsplit-dwarf -c t.ii -o t.o When parser tries to read...

On Thu, Dec 15, 2016 at 11:35 AM Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Dec 15, 2016, at 10:54 AM, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Branching off from a discussion of improvements to DIGlobalVariable > representations that Adrian's working on - got me thinking about related > changes that have

...ary size: 1,3G > compilation time: 128 sec > run-time memory: 17G > > Detailed size results: > > 1. a) > > FILE SIZE VM SIZE > -------------- -------------- > 41.1% 2.64Mi 0.0% 0 .debug_info > 24.9% 1.60Mi 0.0% 0 .debug_str > 12.6% 827Ki 0.0% 0 .debug_line > 6.5% 428Ki 63.8% 428Ki .text > 4.8% 317Ki 0.0% 0 .strtab > 3.4% 223Ki 0.0% 0 .debug_ranges > 2.0% 133Ki 19.8% 133Ki .eh_frame > 1.7% 110Ki 0.0% 0 .symtab >...

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