search for: dw_at_stmt_list

...0-08-31-ByValArg.cpp > LLVM :: FrontendC/2009-02-17-BitField-dbg.c > LLVM :: FrontendC/2010-01-14-StaticVariable.c > LLVM :: FrontendC/2010-02-16-DbgVarScope.c > LLVM :: FrontendObjC/2009-08-17-DebugInfo.m This is because of @@ -1903,7 +1912,8 @@ addLabel(Die, dwarf::DW_AT_stmt_list, dwarf::DW_FORM_addr, Asm->GetTempSymbol("section_line")); else - addUInt(Die, dwarf::DW_AT_stmt_list, dwarf::DW_FORM_data4, 0); + addSectionOffset(Die, dwarf::DW_AT_stmt_list, dwarf::DW_FORM_addr, + Asm->GetTempSymbol("section_line"));...

On Feb 24, 2011, at 11:36 AM, Devang Patel wrote: > > On Feb 12, 2011, at 2:07 AM, Nathan Jeffords wrote: > >> Hello All, >> >> I have created a set of patches that get dwarf debugging support working for the COFF object file. I also believe I have fixed what appears to be a bug in how line info sections are referred to from the DW_TAG_compile_unit DIE. I have run

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, 0); After compiling several files and linking them together (not only usi...

I updated DwarfDebug to use section offset, instead of hard coding 0, to handle LTO properly. r107202. Thanks for brining this up. - Devang On Tue, Jun 29, 2010 at 11:27 AM, Devang Patel <devang.patel at gmail.com> wrote: > 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, Art...

I've also been looking at debugging with ELF and noticed the same problem as Renato. I just sent a patch to llvmcommits that fixes the problem. DW_at_stmt_list needs to emit a label(and therefore a relocation) for the offset rather a constant 0, then the linker can fixup the offset as it shuffles object files around. Krister On Thu, Aug 26, 2010 at 5:11 AM, Renato Golin <rengolin at systemcall.org>wrote: > On 25 August 2010 18:54, Devang Pate...

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&g...

Hi Devang, Thanks for working on that. Unfortunately after your change it still doesn't work (I've tried x86 and our backend under Linux). The problem is that you put difference between two labels .Lset7 = .Lsection_line_begin-.Lsection_line ## DW_AT_stmt_list and that will be evaluated by assembler to a constant. It has to be a label, not a constant, because it is the linker who knows the correct offset. Artur On Tue, Jun 29, 2010 at 10:18 PM, Devang Patel <devang.patel at gmail.com>wrote: > I updated DwarfDebug to use section offset, inste...

...gt; Thanks for working on that. Unfortunately after your change it still doesn't > work (I've tried x86 and our backend under Linux). What errors exactly you are seeing ? > The problem is that you put difference between two labels > .Lset7 = .Lsection_line_begin-.Lsection_line ## DW_AT_stmt_list > and that will be evaluated by assembler to a constant. It has to be a label, > not a constant, because it is the linker who knows the correct offset. How will linker translate a label into correct offset ? - Devang

On 30 Jun 2010, at 18:40, Devang Patel wrote: > On Wed, Jun 30, 2010 at 1:57 AM, Artur Pietrek <pietreka at gmail.com> > wrote: >> The problem is that you put difference between two labels >> .Lset7 = .Lsection_line_begin-.Lsection_line ## DW_AT_stmt_list >> and that will be evaluated by assembler to a constant. It has to be >> a label, >> not a constant, because it is the linker who knows the correct >> offset. > > How will linker translate a label into correct offset ? Sorry for reviving an old thread (I'm go...

On 26 Aug 2010, at 10:32, Krister Wombell wrote: > I've also been looking at debugging with ELF and noticed the same > problem as > Renato. I just sent a patch to llvmcommits that fixes the problem. > DW_at_stmt_list needs to emit a label(and therefore a relocation) > for the > offset rather a constant 0, then the linker can fixup the offset as it > shuffles object files around. It's not just DW_at_stmt_list, you have to do the same for the pointer to the abbreviation section. Jonas

On 26 August 2010 09:32, Krister Wombell <kuwerty at gmail.com> wrote: > I've also been looking at debugging with ELF and noticed the same problem as > Renato. I just sent a patch to llvmcommits that fixes the problem. > DW_at_stmt_list needs to emit a label(and therefore a relocation) for the > offset rather a constant 0, then the linker can fixup the offset as it > shuffles object files around. Hi Krister, We've applied your patch locally and it solved our problem, thanks! Can somebody review/commit that before 2.8...

...31, 2010, at 2:15 AM, Renato Golin wrote: > On 26 August 2010 09:32, Krister Wombell <kuwerty at gmail.com> wrote: >> I've also been looking at debugging with ELF and noticed the same problem as >> Renato. I just sent a patch to llvmcommits that fixes the problem. >> DW_at_stmt_list needs to emit a label(and therefore a relocation) for the >> offset rather a constant 0, then the linker can fixup the offset as it >> shuffles object files around. > > Hi Krister, > > We've applied your patch locally and it solved our problem, thanks! ... but, as it...

...d28fa29d4b44 lib/CodeGen/AsmPrinter/DwarfDebug.cpp --- a/lib/CodeGen/AsmPrinter/DwarfDebug.cpp Wed Oct 10 20:39:45 2012 +0200 +++ b/lib/CodeGen/AsmPrinter/DwarfDebug.cpp Mon Nov 19 10:31:49 2012 +0100 @@ -567,9 +567,14 @@ NewCU->addUInt(Die, dwarf::DW_AT_low_pc, dwarf::DW_FORM_addr, 0); // DW_AT_stmt_list is a offset of line number information for this // compile unit in debug_line section. - if (Asm->MAI->doesDwarfRequireRelocationForSectionOffset()) - NewCU->addLabel(Die, dwarf::DW_AT_stmt_list, dwarf::DW_FORM_data4, + if (Asm->MAI->doesDwarfRequireRelocationForSectionOffset...

...FreeBSD) and on Windows, both of > the following are labels (i.e., absolute addresses to be relocated by > the linker) as opposed to offsets relative to the relevant section's > start, even though the DWARF standard says they are offsets: > * address of the abbreviation table > * DW_AT_stmt_list > > As you say, dwarf standard says it is an offset. 4. A DW_AT_stmt_list attribute whose value is a section offset to the line number information for this compilation unit. This information is placed in a separate object file section from the debugging information entries themselves. The va...

...le_unit [1] * DW_AT_producer [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 8.0.1 ") DW_AT_language [DW_FORM_data2] (DW_LANG_C99) DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 8.0.1 ") DW_AT_stmt_list [DW_FORM_sec_offset] (0x00000000) DW_AT_comp_dir [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 8.0.1 ") Similarly as above snippet .debug_str is always pointing to 0x00000 for everything. >> >> Can you please help me in finding which part of t...

Hi, I'm trying to compile two files together with debug information but seems that LLVM is getting the DW_AT_stmt_list wrong when ld is linking the final executable. Originally, I tried on ARM with Clang (+llc+gas+ln) and, the object files, the DW_AT_stmt_list were null, as expected. When linking, they should point to the offset in the line table, but all of them are still null, so pointing all to the same line ta...

...<c> DW_AT_producer : (indirect string, offset: 0x0): clang > > version 8.0.1 > > <10> DW_AT_language : 12 (ANSI C99) > > <12> DW_AT_name : (indirect string, offset: 0x0): clang > > version 8.0.1 > > <16> DW_AT_stmt_list : 0x0 > > <1a> DW_AT_comp_dir : (indirect string, offset: 0x0): clang > > version 8.0.1 > > <1e> DW_AT_low_pc : 0x0 > > <22> DW_AT_high_pc : 0x6c > > <1><26>: Abbrev Number: 2 (DW_TAG_subprogram) > >...

Hello, Recently I found binaries produced with LLVM impossible to debug under Windows. This was probably related to the following bug: http://llvm.org/bugs/show_bug.cgi?id=13636 Asm generated from .ll files revealed that some offsets to debug information were incorrect: they were absolute instead of relative to their sections. Following patch seemed to have repaired the problem, so I'm

...# Abbrev [1] 0xb:0x8d DW_TAG_compile_unit > .int Linfo_string0 # DW_AT_producer > .short 12 # DW_AT_language > .int Linfo_string1 # DW_AT_name > .int 0 # DW_AT_low_pc > .int Lsection_line # DW_AT_stmt_list > .int Linfo_string2 # DW_AT_comp_dir > .byte 2 # Abbrev [2] 0x22:0x5d DW_TAG_subprogram > .int Linfo_string3 # DW_AT_name > .byte 1 # DW_AT_decl_file > .byte 2 # DW_AT_decl_line >...

...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 passes the IR verifier without complaint (including the debug into verifier). I can run llc manually on my IR without complaint. However, I am not able to ascertain whether llc runs the debug info verifier by...