search for: gdwarf

Hello all, I am implementing support for .debug_names section (which is introduced in DWARFv5 standard as replacement for .debug_pubnames and .debug_pubtypes). The question is: should usage of DWARF version 5 force generation of .debug_names instead of .debug_pubnames or we can make it just default behavior and provide user with the interface (cmd switch) to use other DWARFv5 features but

...Kb) opened URL ================================================== downloaded 133 Kb * installing *source* package ‘rpart’ ... ** libs i686-pld-linux-gcc -std=gnu99 -I/usr/lib/R/include -D_FORTIFY_SOURCE=2 -fpic -O2 -fno-strict-aliasing -fwrapv -march=i686 -mtune=pentium4 -gdwarf-2 -g2 -c anova.c -o anova.o i686-pld-linux-gcc -std=gnu99 -I/usr/lib/R/include -D_FORTIFY_SOURCE=2 -fpic -O2 -fno-strict-aliasing -fwrapv -march=i686 -mtune=pentium4 -gdwarf-2 -g2 -c anovapred.c -o anovapred.o . . . usersplit.o xval.o -L/usr/lib/R/lib -lR ** R ** data ** moving datasets to...

...2) Instead of emiting multiple .debug_types it suggests to emit multiple .debug_info COMDAT sections. (p375, p376). And it seems currently there is no way to make clang to emit multiple .debug_info with type information like DWARF5 suggests. I tried command line below: -g -fdebug-types-section -gdwarf-5 It still emits .debug_types and does not look there is a flag for emiting multiple .debug_info. Looking at whole LLVM code (lib/mc, lib/CodeGen) actually it seems it is just always assumed .debug_info is a unique section in object. (also not sure why clang emits .debug_types when -gdwarf-5 flag i...

...ingle patch since it shouldn't be very large if we go with a) above. If we go with b) then the MDNode work should be done in isolation first and then the debug info on top of it. > 5> backend change (in DwarfDebug|CompileUnit) to support types shared among compile units > requires gdwarf-2 gdwarf-3 gdwarf-4 support for issues related to ref_addr #5 can and should be done before the rest of them. > All changes should be local to debug info classes except patch #4. What's patch #4? -eric

...------- Patches: Expect the following patches: 1> add flag -gtype-hashing 2> add hash field to DI types 3> modify DIBuilder to use hash instead of MD reference 4> related to issue 3 5> backend change (in DwarfDebug|CompileUnit) to support types shared among compile units requires gdwarf-2 gdwarf-3 gdwarf-4 support for issues related to ref_addr All changes should be local to debug info classes except patch #4.

Hi I am using llvm-dwarfdump to dump the line table with -debug-line option. I compiled my program with -gdwarf-3. I first get the line number and source number for every instruction of the LLVM IR with metadata. Then I try to find the corresponding binary address from the dwarf debug info. However, I noticed that the dwarf table might not always return me the answer and some of the source line and column n...

...e > in isolation first and then the debug info on top of it. What is wrong with smaller patches? My estimation for all the above with a) is about 30K + testing cases. > >> 5> backend change (in DwarfDebug|CompileUnit) to support types shared among compile units >> requires gdwarf-2 gdwarf-3 gdwarf-4 support for issues related to ref_addr > > #5 can and should be done before the rest of them. I prefer to submit patches according to the flow of the compiler, starting from the frontend, then IR, then backend. The testing cases will be added for front end, llvm-link and...

Once ocamlfind is installed, 'make' failed for me with: ocamlfind ocamlc -g -annot -safe-string -warn-error CDEFLMPSUVYZX+52-3 -ccopt '-gdwarf' -package unix -c NBD.ml -o NBD.cmo File "NBD.ml", line 1: Error: Could not find the .cmi file for interface NBD.mli. make[2]: *** [Makefile:823: NBD.cmo] Error 2 I'm not positive that this is the perfect fix, but it at least got the build working for me, and copies from idioms i...

...2) Instead of emiting multiple .debug_types it suggests to emit multiple .debug_info COMDAT sections. (p375, p376). And it seems currently there is no way to make clang to emit multiple .debug_info with type information like DWARF5 suggests. I tried command line below: -g -fdebug-types-section -gdwarf-5 It still emits .debug_types and does not look there is a flag for emiting multiple .debug_info. Looking at whole LLVM code (lib/mc, lib/CodeGen) actually it seems it is just always assumed .debug_info is a unique section in object. (also not sure why clang emits .debug_types when -gdwarf-5 flag i...

...ation first and then the debug info on top of it. > > What is wrong with smaller patches? > My estimation for all the above with a) is about 30K + testing cases. > > > 5> backend change (in DwarfDebug|CompileUnit) to support types shared among > compile units > requires gdwarf-2 gdwarf-3 gdwarf-4 support for issues related to ref_addr > > > #5 can and should be done before the rest of them. > > I prefer to submit patches according to the flow of the compiler, starting > from the frontend, then IR, then backend. > The testing cases will be added for f...

...and then the debug info on top of it. > What is wrong with smaller patches? > My estimation for all the above with a) is about 30K + testing cases. > >> >>> 5> backend change (in DwarfDebug|CompileUnit) to support types shared among compile units >>> requires gdwarf-2 gdwarf-3 gdwarf-4 support for issues related to ref_addr >> >> #5 can and should be done before the rest of them. > I prefer to submit patches according to the flow of the compiler, starting from the frontend, then IR, then backend. > The testing cases will be added for front e...

Hello I am trying to run following test case on Clang compiled output to compare the dwarf inline attributes in the resulting assembly output . /* Inlined inline function must have abstract DIE */ /* { dg-do compile } */ /* { dg-options "-O2 -gdwarf-2 -dA -fpreprocessed" } */ /* { dg-final { scan-assembler "3.*DW_AT_inline" } } */ #1 "test.h" inline int t() { } int q() { t(); } The testcase fails because, DW_AT_inline is not present in assembly output. Could anyone let me know why DW_AT_inline is not emitted with Cl...

...now be strings. That means updating DIBuilder and DwarfDebug, etc is one go, basically. > 3> modify DIBuilder to use hash instead of MD reference > 4> related to issue 3 > 5> backend change (in DwarfDebug|CompileUnit) to support types shared among compile units > requires gdwarf-2 gdwarf-3 gdwarf-4 support for issues related to ref_addr > All changes should be local to debug info classes except patch #4.

...e as follow - why struct s in first test is passed in edx not ecx? - why unsigned b is in second test is passed in stack not edx? - why 'packed' makes a difference? - where can I find relevant code in llvm? I'm using i586, linux, llvm 5.02 Build with "clang++ -std=c++11 -ggdb -O0 -gdwarf-4 -fno-omit-frame-pointer -fno-optimize-sibling-calls -o ref_test ref_test.cpp" (All arguments are used in the function so that they are not optimized out) Tested with gdb (gdb) break* test_suuu (gdb) x/6wx $esp (gdb) i r -------------- next part -------------- An HTML attachment w...

...>>> What is wrong with smaller patches? >>> My estimation for all the above with a) is about 30K + testing cases. >>> >>> >>> 5> backend change (in DwarfDebug|CompileUnit) to support types shared among >>> compile units >>> requires gdwarf-2 gdwarf-3 gdwarf-4 support for issues related to ref_addr >>> >>> >>> #5 can and should be done before the rest of them. >>> >>> I prefer to submit patches according to the flow of the compiler, starting >>> from the frontend, then IR, then bac...

...o on top of it. >> >> What is wrong with smaller patches? >> My estimation for all the above with a) is about 30K + testing cases. >> >> >> 5> backend change (in DwarfDebug|CompileUnit) to support types shared among >> compile units >> requires gdwarf-2 gdwarf-3 gdwarf-4 support for issues related to ref_addr >> >> >> #5 can and should be done before the rest of them. >> >> I prefer to submit patches according to the flow of the compiler, starting >> from the frontend, then IR, then backend. >> The te...

...ns > updating DIBuilder and DwarfDebug, etc is one go, basically. > >> 3> modify DIBuilder to use hash instead of MD reference >> 4> related to issue 3 >> 5> backend change (in DwarfDebug|CompileUnit) to support types shared among compile units >> requires gdwarf-2 gdwarf-3 gdwarf-4 support for issues related to ref_addr >> All changes should be local to debug info classes except patch #4.

...olation first and then the debug info on top of it. > > What is wrong with smaller patches? > My estimation for all the above with a) is about 30K + testing cases. > > > 5> backend change (in DwarfDebug|CompileUnit) to support types shared among > compile units > requires gdwarf-2 gdwarf-3 gdwarf-4 support for issues related to ref_addr > > > #5 can and should be done before the rest of them. > > I prefer to submit patches according to the flow of the compiler, starting > from the frontend, then IR, then backend. > The testing cases will be added for f...

...g with smaller patches? >>>> My estimation for all the above with a) is about 30K + testing cases. >>>> >>>> >>>> 5> backend change (in DwarfDebug|CompileUnit) to support types shared among >>>> compile units >>>> requires gdwarf-2 gdwarf-3 gdwarf-4 support for issues related to ref_addr >>>> >>>> >>>> #5 can and should be done before the rest of them. >>>> >>>> I prefer to submit patches according to the flow of the compiler, starting >>>> from the...

...deduplicating COMDATs, so generally such object is not a problem as already supported, but for error reporting purposes and for --gdb-index we assume debug sections are unique in object, so in that case we looks want to error out). Have last thoughts/question about this though :) Currently clang -gdwarf-5 -fdebug-types-section​ works. And so linker can deduplicate types. Though that probably violates specification saying there is no more .debug_type sections. But behavior is convinent for users of -fdebug-types-section. I do not know how transition from v4 to v5 will happen/happens (or how transit...