search for: debug_lin

In CodeGen/DwarfWriter.cpp's EmitDebugLine file, these lines are causing havoc on Mac OS X systems: // If there are no lines to emit (such as when we're using .loc directives // to emit .debug_line information) don't emit a .debug_line header. if (SectionSourceLines.empty()) return; Basically, if there's a file with only data in it, we still need the debug_line prologue generated. $ cat a.c const char ver[] __attribute__((used)) = "Hello world\n"; $ gcc -g -O0 -...

On Jul 17, 2008, at 3:33 PM, Bill Wendling wrote: > In CodeGen/DwarfWriter.cpp's EmitDebugLine file, these lines are > causing havoc on Mac OS X systems: > > // If there are no lines to emit (such as when we're using .loc > directives > // to emit .debug_line information) don't emit a .debug_line > header. > if (SectionSourceLines.empty()) > return; The fix is to move the early exist to just below this line: EmitLabel("line_prolog_end", 0), right? > > > Basically, if there's a file with only data in it,...

I'm working on adding source-based profiling support for MCJIT and in the process of implementing this, I came across a test case where an object is being generated that wants to have relocations applied to the .debug_line section. I see in the DebugInfo code that it currently only supports relocations applied to either the .debug_info or the .debug_info.dwo section. Can anyone give me an overview of what I would need to do to extend this to handle the .debug_line section also? Thanks, Andy -------------- next pa...

...adding a map for a section with a > different purpose would work -- that is, whether it should be yet another > member variable in DWARFContextInMemory or if there was some better way to > combine them.**** > > ** > *shrug* I've been adding them as needed. I knew I needed the debug_line table, but I've been mostly adding that stuff as I need it to fix something else. Right now I think we're only going to ultimately need a couple of them so just adding them as fields sounds fine. > ** > > It also wasn’t clear to me what the relocation map was doing anyway and &g...

...for a section with a different purpose would work -- that is, whether it should be yet another member variable in DWARFContextInMemory or if there was some better way to combine them. It also wasn't clear to me what the relocation map was doing anyway and what would need to be changed for the .debug_line section, but I suppose that was mostly laziness on my part, hoping that you had a plan that you could just spell out for me. Having overcome my laziness a bit today and looked at the code some more, it looks like I'd need to pass the new map (however it was stored) into DWARFDebugLine and hav...

...4:53 PM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > I’m working on adding source-based profiling support for MCJIT and in > the process of implementing this, I came across a test case where an object > is being generated that wants to have relocations applied to the > .debug_line section. I see in the DebugInfo code that it currently only > supports relocations applied to either the .debug_info or the > .debug_info.dwo section.**** > > ** ** > > Can anyone give me an overview of what I would need to do to extend this > to handle the .debug_line sectio...

...all the JITed functions are in the same section. The problem is that I have a test case that is trying to reference an inlined function. In this case, the generated object puts the 'inlined' function in a separate section (I'm not clear why that is) and generates relocations for the .debug_line section. Since these relocations are never applied, I end up with multiple sequences in the line table claiming to be at address zero. FWIW, if I use whatever 'dwarfdump' is on my Linux box to look at the generated object, it shows me a line table with multiple entries claiming to be at...

...v4 directory table is encoded.) However, because of the FORM code, we now have whole new worlds of complication regarding where the actual string might be. We might have DW_FORM_strp which puts the actual string in the .debug_string section; eventually we could have DW_FORM_line_str (pointing to .debug_line_str) or even DW_FORM_strx (indirecting through .debug_str_offsets). Conveniently, we have the DWARFFormValue class which knows how to decode data based on what the form code is. Inconveniently, DWARFFormValue assumes it is looking at a .debug_info section, and picks up its relocations from a DWA...

I'm using LLVM 2.8 with GNU Binutils for Ubuntu 2.20.51-system.20100908. When I try to assemble a .s file generated with llc with g++ I get the error: Fatal error: duplicate .debug_line sections. I'm using llvm-gcc/g++ as front end. I also tried generating the .o file directly using -filetype=obj but that too fails with BFD: BFD (GNU Binutils for Ubuntu) 2.20.51-system.20100908 assertion fail ../../bfd/elf.c:1805 when trying to convert the .o file to an archive with ar....

...> ** > OK. > ** > > > > The problem is that I have a test case that is trying to reference an > inlined function. In this case, the generated object puts the ‘inlined’ > function in a separate section (I’m not clear why that is) and generates > relocations for the .debug_line section. Since these relocations are never > applied, I end up with multiple sequences in the line table claiming to be > at address zero.**** > > ** ** > > FWIW, if I use whatever ‘dwarfdump’ is on my Linux box to look at the > generated object, it shows me a line table with...

Great, thanks! Those results are about roughly what I was expecting. I assume "compilation time" is actually just the link time? I find it particularly interesting that the DWARFLinker rewriting solution produces the same size improvement in .debug_line as the fragmented DWARF approach. That suggests that in that case, fragmented DWARF output is probably about as optimal as it can get. I'm not surprised that the same can't be said for other sections, but I'm also pleased to see that the full rewrite option isn't so much better in...

The impact to debug_line is actually not small. I only implemented the part 1 (encoding duplication factor) for loop unrolling and loop vectorization. The debug_line size overhead for "-O2 -g1" binary of speccpu C/C++ benchmarks: 433.milc 23.59% 444.namd 6.25% 447.dealII 8.43% 450.soplex 2.41% 453.povray 5.40%...

The large percentages are from those tiny benchmarks. If you look at omnetpp (0.52%), and xalanc (1.46%), the increase is small. To get a better average increase, you can sum up total debug_line size before and after and compute percentage accordingly. David On Thu, Oct 27, 2016 at 1:11 PM, Dehao Chen <dehao at google.com> wrote: > The impact to debug_line is actually not small. I only implemented the > part 1 (encoding duplication factor) for loop unrolling and loop > v...

Hi all, While implementing debug info for our backend, we've noticed a problem with debug_line section. We believe that the following code is wrong: // DW_AT_stmt_list is a offset of line number information for this // compile unit in debug_line section. It is always zero when only one // compile unit is emitted in one object file. addUInt(Die, dwarf::DW_AT_stmt_list, dwarf::DW_FORM_data4,...

...e52db004 push {fp} ; (str fp, [sp, #-4]!) 8464: e28db000 add fp, sp, #0 /* Some linkers (e.g. on AIX) remove unreferenced variables, so make sure to reference them. */ v_char = 'A'; Raw dump of debug contents of section .debug_line: Offset: 0x0 Length: 74 *DWARF Version: 2 * Prologue Length: 34 Minimum Instruction Length: 2 Initial value of 'is_stmt': 1 Line Base: -5 Line Range:...

Hello, A recent series of commits, ending with r169304 and relating to PR13303, add is_stmt to line entries for functions. This appears to be to work around problems with gdb. However, I observe is_stmt is not always applied to line entries for functions. This may only affect the arm backend. Compiling the same code with the aarch64 backend does not demonstrate this problem. It seems that

...compilation unit generated per .o file then it is always zero. What kind of errors are you seeing ? - Devang On Tue, Jun 29, 2010 at 9:02 AM, Artur Pietrek <pietreka at gmail.com> wrote: > Hi all, > While implementing debug info for our backend, we've noticed a problem with > debug_line section. We believe that the following code is wrong: > // DW_AT_stmt_list is a offset of line number information for this > // compile unit in debug_line section. It is always zero when only one > // compile unit is emitted in one object file. > addUInt(Die, dwarf::DW_AT_stmt_list, dw...

Hello > The prologue length in .debug_line is 157 for clang generated one, whereas > it is 34 for gcc generated one. I am curious about the results of making > prologue generated by clang look similar with one generated by gcc. > Could anyone let me know why this difference exists and if it is for good > /better purposes than f...

Do you have an estimate of the debug_line size increase? I guess it will be small. David On Thu, Oct 27, 2016 at 11:39 AM, Dehao Chen <dehao at google.com> wrote: > Motivation: > Many optimizations duplicate code. E.g. loop unroller duplicates the loop > body, GVN duplicates computation, etc. The duplicated code will sha...

...tions prematurely terminating the list), while >> >letting users who want to experiment with it, or need it (like Alexey), can >> >opt-in to the -1/-2 behavior. >> >> I think we can only confidently say that there is enough risk in using >> tombstone value -1 in .debug_line, but I'd not say tombstone value -1 in >> other .debug_* can cause problems. >Given how many DWARF parsers we've had to cleanup or migrate off in >transitioning to DWARFv5 inside Google, I think that's a fair bit of >evidence the set of parsers isn't as narrow/close...