search for: debug_abbrev

On 5/21/20, Adrian Prantl <aprantl at apple.com> wrote: > I think the example looks like it would be really useful for many categories > of testcases! > Will it still be possible to manually specify the .debug_abbrev section when > this is desired after you are done? Yes, I think it works. There are two ways to edit the .debug_abbrev section. i) Edit the "Attr:" and "Form:" entries of a DIE in the ".debug_info" section. This controls the generation of the ".debug_abbrev&q...

Hello all, it looks like we have a bug here but I am not sure. Currently if we have two similar types with implicit_const attributes and different values we end up with only one abbrev in .debug_abbrev section. For example consider two structures: S1 with implicit_const attribute ATTR and value VAL1 and S2 with implicit_const ATTR and value VAL2. The .debug_abbrev section will contain only 1 related record: [N] DW_TAG_structure_type DW_CHILDREN_yes DW_AT_ATTR DW_FORM_imp...

Hi folks, I am going to implement DWARF support for yaml2obj. I really appreciate it that many of you have given me a lot of useful comments and suggestions in the previous thread [1]. I've had some offline discussions with James and done some updates to the previous proposal. This proposal addresses the issue of properly describing the DWARF sections in YAML both at a high level and at a

...scriptions. For example, if > each "abbrev" contribution had some kind of a name/identifier, then one > could easily express that two compile units share the same abbreviation > table. At the same time, one could control their relative order by using > those identifiers in the debug_abbrev section (while leaving some of > them to be auto-generated, and spelling out others, for instance). Nice catch! It's a useful feature, but I cannot give an answer right now. I will be back to this thread, once I have some ideas on this. > - It's not clear to me whether having a &quo...

...lvm.org/show_bug.cgi?id=39862 I'm trying to enable stack traces in an OS kernel. To do that the kernel needs access to its own debug info. I have this in my linker script: .debug_info : { __debug_info_start = .; KEEP(*(.debug_info)) __debug_info_end = .; } .debug_abbrev : { __debug_abbrev_start = .; KEEP(*(.debug_abbrev)) __debug_abbrev_end = .; } .debug_str : { __debug_str_start = .; KEEP(*(.debug_str)) __debug_str_end = .; } .debug_line : { __debug_line_start = .; KEEP(*(.debug_line)...

...support this properly, while LLVM command line tools don't: $ ld --version GNU gold (GNU Binutils for Ubuntu 2.22) 1.11 $ ./bin/clang++ -g a.cc -Wl,--compress-debug-sections=zlib $ objdump -h a.out | grep debug 26 .debug_info 00000066 0000000000000000 0000000000000000 00002010 2**0 27 .debug_abbrev 00000048 0000000000000000 0000000000000000 00002068 2**0 28 .debug_aranges 00000000 0000000000000000 0000000000000000 000020bb 2**0 29 .debug_macinfo 00000000 0000000000000000 0000000000000000 000020cf 2**0 30 .debug_line 00000053 0000000000000000 0000000000000000 000020e3 2**0...

.... The responsibility for generating debug information is split between the PTX producer and the PTX-to-SASS backend. The PTX producer is responsible for emitting binary DWARF into the PTX file, using the .section and .b8-.b16-.b32-and-.b64 directives in PTX. This should contain the .debug_info and .debug_abbrev sections, and possibly optional sections .debug_pubnames and .debug_aranges. These sections are standard DWARF2 sections that refer to labels and registers in the PTX. The PTX-to-SASS backend is responsible for generating the .debug_line section from the .file and .loc directives in the PTX file....

..., since the addresses of sections will be non-contiguous. From there, you should be able to edit the .debug_ranges assembly as needed (replace references to symbols with 0s in the .debug_ranges content) to get the exact behaviour you want (I'm assuming you don't want to have to hand-edit a .debug_abbrev/.debug_info data structure to manually create a .debug_ranges). On Sun, 26 Apr 2020 at 22:17, Greg Clayton via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Personally I generate DWARF with a python DWARF generator I wrote so I can > make minimal test cases. I often can't get th...

...]) > { > int a = 11; > int b = 22; > int c = a+b; > return c; > } > > ###################################### > # asm including dwarf debugging info > .file "test.c" > .section .debug_info,"", at progbits > Lsection_info: > .section .debug_abbrev,"", at progbits > Lsection_abbrev: > .section .debug_aranges,"", at progbits > .section .debug_macinfo,"", at progbits > .section .debug_line,"", at progbits > Lsection_line: > .section .debug_loc,"", at progbits > .section .de...

I recently upgraded a codebase to use LLVM 3.9.0, up from 3.7.1. All seems to work well, except that I am unable to generate debug information. However, if I run objdump -g on the generated object file, it reports that the compile unit has no children: Contents of the .debug_abbrev section: Number TAG (0x0) 1 DW_TAG_compile_unit [no children] DW_AT_producer DW_FORM_strp DW_AT_language DW_FORM_data2 DW_AT_name DW_FORM_strp DW_AT_stmt_list DW_FORM_sec_offset DW_AT value: 0 DW_FORM value: 0 The IR generated for 3.9.0 pass...

...OCK(__section_alignment__) (NOLOAD) : { *(.zdebug_pubtypes) } /* DWARF 2. */ .debug_info BLOCK(__section_alignment__) (NOLOAD) : { *(.debug_info .gnu.linkonce.wi.*) } .zdebug_info BLOCK(__section_alignment__) (NOLOAD) : { *(.zdebug_info .zdebug.gnu.linkonce.wi.*) } .debug_abbrev BLOCK(__section_alignment__) (NOLOAD) : { *(.debug_abbrev) } .zdebug_abbrev BLOCK(__section_alignment__) (NOLOAD) : { *(.zdebug_abbrev) } .debug_line BLOCK(__section_alignment__) (NOLOAD) : { *(.debug_line) } .zdebug_line BLOCK(__section_alignment__) (NOLOAD) : {...

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

...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 > 1.2% 77.6Ki 0.0% 0 .debug_abbrev > > b) > > FILE SIZE VM SIZE > -------------- -------------- > 40.2% 2.10Mi 0.0% 0 .debug_info > 30.7% 1.60Mi 0.0% 0 .debug_str > 8.0% 428Ki 63.8% 428Ki .text > 5.9% 317Ki 0.0% 0 .strtab > 5.9%...

...; >> $ ld --version >> GNU gold (GNU Binutils for Ubuntu 2.22) 1.11 >> $ ./bin/clang++ -g a.cc -Wl,--compress-debug-sections=zlib >> $ objdump -h a.out | grep debug >> 26 .debug_info 00000066 0000000000000000 0000000000000000 00002010 >> 2**0 >> 27 .debug_abbrev 00000048 0000000000000000 0000000000000000 00002068 >> 2**0 >> 28 .debug_aranges 00000000 0000000000000000 0000000000000000 000020bb >> 2**0 >> 29 .debug_macinfo 00000000 0000000000000000 0000000000000000 000020cf >> 2**0 >> 30 .debug_line 000000...

...ecently upgraded a codebase to use LLVM 3.9.0, up from 3.7.1. > > All seems to work well, except that I am unable to generate debug information. > > However, if I run objdump -g on the generated object file, it reports that the compile unit has no children: > > Contents of the .debug_abbrev section: > > Number TAG (0x0) > 1 DW_TAG_compile_unit [no children] > DW_AT_producer DW_FORM_strp > DW_AT_language DW_FORM_data2 > DW_AT_name DW_FORM_strp > DW_AT_stmt_list DW_FORM_sec_offset > DW_AT value: 0 DW_FORM v...

...debug information is >> split between the PTX producer and the PTX-to-SASS backend. The PTX >> producer is responsible for emitting binary DWARF into the PTX file, >> using the .section and .b8-.b16-.b32-and-.b64 directives in PTX. This >> should contain the .debug_info and .debug_abbrev sections, and possibly >> optional sections .debug_pubnames and .debug_aranges. These sections >> are standard DWARF2 sections that refer to labels and registers in the >> PTX. >> >> The PTX-to-SASS backend is responsible for generating the .debug_line >> section...

...aries you're > looking at haven't been string-merged? As an example, here are the numbers for a fresh built CLANG in Debug mode on Ubuntu 20.04 using GCC 10.2: $ readelf -SW clang-12 | grep debug | awk '{print $2, $6}' | column -t .debug_aranges 00c240 .debug_info 34d1fd .debug_abbrev 00841f .debug_line 023093 .debug_str 53685f .debug_ranges 00c300 As you can see, ".debug_str" is visibly bigger than ".debug_info". Of course, CLANG does not suffer from DWARF32 limits. This is just a relatively large project, which anyone can easily check by the...

..._pubtypes) > } > /* DWARF 2. */ > .debug_info BLOCK(__section_alignment__) (NOLOAD) : > { > *(.debug_info .gnu.linkonce.wi.*) > } > .zdebug_info BLOCK(__section_alignment__) (NOLOAD) : > { > *(.zdebug_info .zdebug.gnu.linkonce.wi.*) > } > .debug_abbrev BLOCK(__section_alignment__) (NOLOAD) : > { > *(.debug_abbrev) > } > .zdebug_abbrev BLOCK(__section_alignment__) (NOLOAD) : > { > *(.zdebug_abbrev) > } > .debug_line BLOCK(__section_alignment__) (NOLOAD) : > { > *(.debug_line) > } >...

Hi, all I ported llvm backend and lldb recently. Both tools can basically work. lldb is able to debug programs in asm style and frame unwinding is OK. But "frame variable XX" does not work because lldb is not able to determine the address of XX from debug info. Can someone give any clue? Thanks in advance. -- 杨勇勇 (Yang Yong-Yong) -------------- next part -------------- An HTML

...ne tools > don't: > > $ ld --version > GNU gold (GNU Binutils for Ubuntu 2.22) 1.11 > $ ./bin/clang++ -g a.cc -Wl,--compress-debug-sections=zlib > $ objdump -h a.out | grep debug > 26 .debug_info 00000066 0000000000000000 0000000000000000 00002010 > 2**0 > 27 .debug_abbrev 00000048 0000000000000000 0000000000000000 00002068 > 2**0 > 28 .debug_aranges 00000000 0000000000000000 0000000000000000 000020bb > 2**0 > 29 .debug_macinfo 00000000 0000000000000000 0000000000000000 000020cf > 2**0 > 30 .debug_line 00000053 0000000000000000 00...