search for: debug_lines

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

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()) >

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

On Thu, Jan 10, 2013 at 4:42 PM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > Well, I saw the .debug_info.dwo stuff (though I didn’t realize it was so > recent), but it wasn’t clear to me how 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

Well, I saw the .debug_info.dwo stuff (though I didn't realize it was so recent), but it wasn't clear to me how 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. It also wasn't clear to me what the relocation map was doing anyway and what

That relocation handling is only done for the llvm-dwarfdump binary. MCJIT handles relocations a bit different. I think you just need to go ahead and allow the MCJIT relocation handling machinery to work on non-alloc sections and it should go ahead and handle these just fine, unless you're using the existing stuff in lib/DebugInfo to print out information or something? If this isn't what

Actually, MCJIT doesn't perform relocations on debug sections. I'm not sure that would matter anyway. The place where I'm handling the debug information is outside MCJIT and the MCJIT relocation code isn't really accessible at that point. Right now, when MCJIT emits an object image, it broadcasts an event to any registered listeners indicating that an object was emitted, passing

The next feature on my DWARF 5 list is the line-table header. While this is pretty easy generate, it is a real bear to parse, so I thought I should let y'all know what I'm up to and why as I head out to the yak farm. Any thoughts and suggestions would be very much appreciated. The v5 directory and file tables no longer have a fixed format; instead, we have a list of field descriptors

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

On Thu, Jan 10, 2013 at 3:13 PM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > Actually, MCJIT doesn’t perform relocations on debug sections. I’m not > sure that would matter anyway. The place where I’m handling the debug > information is outside MCJIT and the MCJIT relocation code isn’t really > accessible at that point.**** > > ** > I know it doesn't,

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.

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% 470.lbm 0.00% 482.sphinx3 7.10% 400.perlbench 2.77% 401.bzip2 9.62% 403.gcc

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

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,

1. I would like to know why there is a difference in function prologue generated for same function with clang and gcc. Compiler options used for gcc were as follows: arm-linux-gnueabi-gcc all-types.c -w -march=armv7-a -mtune=cortex-a8 -mfloat-abi=softfp -mfpu=vfp -g -lm -o all-types_gcc Compiler options used for clang were as follows: /usr/local/bin/clang all-types.c -w

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

DW_AT_stmt_list attribute's value is a section offset to the line no info for current compilation unit. If there is only one 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

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 for gcc. ? 1. This is not function prologue length.

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 share the > same debug info with the original code. For

>Пятница, 17 июля 2020, 19:42 +03:00 от David Blaikie <dblaikie at gmail.com>: > >On Fri, Jul 17, 2020 at 12:03 AM Fangrui Song < maskray at google.com > wrote: >> >> Thanks for the write-up! >> >> On 2020-07-16, David Blaikie wrote: >> >In short: Perhaps we should switch lld to the bfd-style tombstoning >> >behavior for a release or