search for: debug_info

...e that. Thanks, Take the mcf program in SPEC2K6 as example. The compiling options are : clang -O0 -c -emit-llvm -o obj/mcf.o -g -DSPEC_CPU mcf.c llvm-link -o mcf.bc obj/mcf.o opt -o mcf.opt.bc mcf.bc -O2 llc -O0 -relocation-model=static -o mcf.s mcf.opt.bc clang mcf.s -o mcf /tmp/mcf-CvkpnA.o:(.debug_info+0x48d): undefined reference to `.Lline_table_start1' /tmp/mcf-CvkpnA.o:(.debug_info+0x894): undefined reference to `.Lline_table_start2' /tmp/mcf-CvkpnA.o:(.debug_info+0xfce): undefined reference to `.Lline_table_start3' /tmp/mcf-CvkpnA.o:(.debug_info+0x1226): undefined reference to `.L...

...gram in SPEC2K6 as example. The compiling options are : > > clang -O0 -c -emit-llvm -o obj/mcf.o -g -DSPEC_CPU mcf.c > llvm-link -o mcf.bc obj/mcf.o > opt -o mcf.opt.bc mcf.bc -O2 > llc -O0 -relocation-model=static -o mcf.s mcf.opt.bc > clang mcf.s -o mcf > /tmp/mcf-CvkpnA.o:(.debug_info+0x48d): undefined reference to `.Lline_table_start1' > /tmp/mcf-CvkpnA.o:(.debug_info+0x894): undefined reference to `.Lline_table_start2' > /tmp/mcf-CvkpnA.o:(.debug_info+0xfce): undefined reference to `.Lline_table_start3' > /tmp/mcf-CvkpnA.o:(.debug_info+0x1226): undefined r...

...ogram in SPEC2K6 as example. The compiling options are : > > clang -O0 -c -emit-llvm -o obj/mcf.o -g -DSPEC_CPU mcf.c > llvm-link -o mcf.bc obj/mcf.o > opt -o mcf.opt.bc mcf.bc -O2 > llc -O0 -relocation-model=static -o mcf.s mcf.opt.bc > clang mcf.s -o mcf > /tmp/mcf-CvkpnA.o:(.debug_info+0x48d): undefined reference to > `.Lline_table_start1' > /tmp/mcf-CvkpnA.o:(.debug_info+0x894): undefined reference to > `.Lline_table_start2' > /tmp/mcf-CvkpnA.o:(.debug_info+0xfce): undefined reference to > `.Lline_table_start3' > /tmp/mcf-CvkpnA.o:(.debug_info+0x122...

Hi all ! We have an issue with LLD, it is "relocation R_X86_64_32 out of range" (PR31109) which occurs during resolving relocations in debug sections. It looks happens because .debug_info section can be too large sometimes and 32x relocation is not enough to represent the value. One of possible 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 suggest...

...The compiling options are : >> >> clang -O0 -c -emit-llvm -o obj/mcf.o -g -DSPEC_CPU mcf.c >> llvm-link -o mcf.bc obj/mcf.o >> opt -o mcf.opt.bc mcf.bc -O2 >> llc -O0 -relocation-model=static -o mcf.s mcf.opt.bc >> clang mcf.s -o mcf >> /tmp/mcf-CvkpnA.o:(.debug_info+0x48d): undefined reference to >> `.Lline_table_start1' >> /tmp/mcf-CvkpnA.o:(.debug_info+0x894): undefined reference to >> `.Lline_table_start2' >> /tmp/mcf-CvkpnA.o:(.debug_info+0xfce): undefined reference to >> `.Lline_table_start3' >> /tmp/mcf-Cvk...

...>>> >>> clang -O0 -c -emit-llvm -o obj/mcf.o -g -DSPEC_CPU mcf.c >>> llvm-link -o mcf.bc obj/mcf.o >>> opt -o mcf.opt.bc mcf.bc -O2 >>> llc -O0 -relocation-model=static -o mcf.s mcf.opt.bc >>> clang mcf.s -o mcf >>> /tmp/mcf-CvkpnA.o:(.debug_info+0x48d): undefined reference to >>> `.Lline_table_start1' >>> /tmp/mcf-CvkpnA.o:(.debug_info+0x894): undefined reference to >>> `.Lline_table_start2' >>> /tmp/mcf-CvkpnA.o:(.debug_info+0xfce): undefined reference to >>> `.Lline_table_start3' &...

...>> >> I guess that the relative size of the ".debug_str" section may vary and depends on the source code, particular build environment, and lots of other circumstances. I've checked some fresh built samples and always see that the section is usually close in size to ".debug_info" and sometimes even bigger. So, this section must be ordered similarly as all other debugging info sections. > > I agree with Paul, and I'm surprised by your findings. Can you post > some actual numbers? In my experience, .debug_str is an order of > magnitude smaller than .deb...

...ompilations and link them all together, in a fairly traditional model, and that is where type sections will provide the most benefit. Your data, then, is essentially for a best-case scenario. Other kinds of projects will not benefit as much. Regarding DWARF 5 and emitting type sections into the .debug_info section rather than the .debug_types section: The work to support DWARF 5 in LLVM has not gotten very far yet. Conforming to the standard in this respect is certainly on my list, however there are other features that Sony considers higher priority. If you or someone else wants to contribute that...

...particular case. Hi Devang, Ok, got the background, but will reply on this email. As far as I understood, there is nothing wrong with the way clang deals with stmt_list. The encoding is correct (AFAIK) and the offsets are always zero in every object file, as there is only one line table and one debug_info. The problem is during link time. GCC also generated zero for stmt_list in the objects but links correctly in the end. I still haven't figured out which type of relocation is needed. All I know is that GCC generates .rel.debug_info relocations that clang doesn't: clang: ** Section #6 ...

...M devs, I've noticed that LLVM's assembler (and hence clang) doesn't generate debug data when assembling, even when run with "-g". Users can add their own CFI/line number data with assembler directives. But GDB ignores the line number data if you don't have a DIE in the .debug_info section which identifies the compilation unit. (I'm not an expert on GDB, but this is the conclusion I have drawn from single-stepping through GDB on some test binaries.) Would you be interested in a patch which makes the assembler generate .debug_info? Thanks, Alex Dowad -------------- next...

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, depending on DWARF format. > >A situat...

...ARF-64 concerns. I guess that the relative size of the ".debug_str" section may vary and depends on the source code, particular build environment, and lots of other circumstances. I've checked some fresh built samples and always see that the section is usually close in size to ".debug_info" and sometimes even bigger. So, this section must be ordered similarly as all other debugging info sections. -- Best Regards, Igor Kudrin C++ Developer, Access Softek, Inc.

...llvm- > dev at lists.llvm.org; Robinson, Paul <paul.robinson at sony.com>; James > Henderson <jh7370.2008 at my.bristol.ac.uk>; Eric Christopher > <echristo at gmail.com>; Igor Kudrin <ikudrin at accesssoftek.com> > 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 referenc...

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, depending on DWARF format. A situation we m...

...PM, Alex <alexinbeijing at gmail.com> wrote: > Dear LLVM devs, > > I've noticed that LLVM's assembler (and hence clang) doesn't generate > debug data when assembling, even when run with "-g". > Sorry, let me correct that: the assembler does generate the .debug_info section (as well as line number data) when run with "-g". I was wrong, sorry. The issue I am having with GDB is occurring because using ".file" directives with LLVM's assembler doesn't automatically add DW_TAG_compile_unit DIEs to the .debug_info and .debug_aranges sect...

...ases 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_ref4 has a value 0x0000055c that is not in the current compile unit in the .debug_...

See "DwarfDebug problem with line section" thread on llvmdev. Bottom line, we may need a target specific patch for targets that do not follow dwarf standard (as per my reading) in this particular case. - Devang On Wed, Aug 25, 2010 at 5:49 AM, Renato Golin <rengolin at systemcall.org>wrote: > Hi, > > I'm trying to compile two files together with debug information

Hello DWARF fans, I've just posted a set of four refactoring patches for DebugInfo/DWARF, which move in the direction of handling DWARF v4 or v5 type units and compile units more coherently. In DWARF v4, type units and compile units are strictly segregated into the .debug_types and .debug_info sections, respectively. This division was pretty ingrained into how DebugInfo/DWARF handled the units. In DWARF v5, type units and compile units are all in the .debug_info section, and the .debug_types section is obsolete. So, we need to have a container than can handle both kinds of units in a...

...ses 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 DwarfDebug.cpp or how debug info is generated by FE. In DwarfDebug.cpp, you'...

...ork with sections as pieces and should not know about content. That is not always possible, for example we have to look inside .eh_frame to deuplicate FDEs, but that is probably what we would want to avoid in general. >It doesn't seem especially important to implement the DWARF5 types -> debug_info thing for this situation, the type units >as they are (in debug_types) offer the same size benefits here. But sure, if anyone wanted to implement it at some point, that'd be fine. But there is no .debug_types in DWARF5, so it is depricated approach as far I understand. >I think Paul cov...