similar to: [LLVMdev] dwarf directory table and file table

Hi Nick, On Aug 2, 2011, at 6:56 PM, Nick Lewycky wrote: > I've been looking into the debug info in llvm recently. After conferring with a DWARF expert, I think what we really want for a file is to enter the actual name of the header that the preprocessor found between "" or <> on the #include line, and for the directory it should be the actual header search path used.

On 2 August 2011 20:02, Devang Patel <dpatel at apple.com> wrote: > Hi Nick, > > On Aug 2, 2011, at 6:56 PM, Nick Lewycky wrote: > > > I've been looking into the debug info in llvm recently. After conferring > with a DWARF expert, I think what we really want for a file is to enter the > actual name of the header that the preprocessor found between "" or

It seems to me that emitting DWARF line number information using .loc directives is currently broken. CellSPU is currently the only in tree target that sets HasDotLocAndDotFile in its MCAsmInfo and I can't get it to produce any line number information. Is this a known issue? I understand that there are lots of changes going on in this area. Any idea what it would take to fix? -- Richard

Richard Osborne wrote: > It seems to me that emitting DWARF line number information using .loc > directives is currently broken. CellSPU is currently the only in tree > target that sets HasDotLocAndDotFile in its MCAsmInfo and I can't get it > to produce any line number information. > I think I understand why this is happening. Since HasDotLocAndDotFile is set the

>> Does anybody know what the bug is in GDB that this works around? The >> workaround was added as part of r103439[1], which added support for >> multiple compilation units in one module. Does the bug ever affect >> modules with only a single compilation unit? >> > > It was not added by r103439. In fact, it was added by r32035. > >

On Apr 13, 2011, at 11:15 AM, Chris Lattner wrote: >>> Does anybody know what the bug is in GDB that this works around? The >>> workaround was added as part of r103439[1], which added support for >>> multiple compilation units in one module. Does the bug ever affect >>> modules with only a single compilation unit? >>> >> >> It was not

> On Mar 31, 2020, at 10:55 AM, David Blaikie <dblaikie at gmail.com> wrote: > > +1 to all that & cc'ing a few of the usual suspects as FYI > > On Tue, Mar 31, 2020 at 10:36 AM Pavel Labath via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > For me personally, the ability to write/edit syntactically

On Feb 24, 2011, at 11:52 AM, Devang Patel wrote: > > 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

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

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

Hi all, Since December, I've made several changes to the DWARF debug line parser to improve its error handling. Some examples include removing redundant error checks[1] and making address size mismatches non-fatal to parsing[2], with several more about to land or being planned. David Blaikie recommended I post something to give a bit more context to these changes. I am a member of Sony's

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.

On Tue, Jan 22, 2013 at 6:22 PM, Robinson, Paul <Paul.Robinson at am.sony.com> wrote: > David Blaikie [dblaikie at gmail.com] wrote: >> On Tue, Jan 22, 2013 at 3:23 PM, Robinson, Paul >> <Paul.Robinson at am.sony.com> wrote: >>>>>> 2. Relying of assembly directive emissions (i.e. .cfi_*), which is >>>>>> cumbersome and misses a lot of

On Mon, 27 Jan 2020 at 23:22, David Blaikie <dblaikie at gmail.com> wrote: > Thanks for all the work & context, James! > Thanks for the reviews! > > On Mon, Jan 27, 2020 at 5:51 AM James Henderson < > jh7370.2008 at my.bristol.ac.uk> wrote: > >> Hi all, >> >> Since December, I've made several changes to the DWARF debug line parser

What does gcc do? On Fri, Aug 24, 2018 at 9:05 AM via llvm-dev <llvm-dev at lists.llvm.org> wrote: > There are two forms of the .file directive. One is simply > > .file "path" > > and the other is > > .file <file-number> [ "dir"] "path" [ …. other stuff ] > > > > The latter is sometimes

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

Hi all, I am processing DWARF line and column information in (x86 and ARM) executables in order to produce a mapping from the machine instructions back to the original source code (C/C++). Using the line numbers is quite straightforward ("libdwarf" [1] is doing the work me.) But when comparing the column numbers (extracted from the DWARF line table) with the corresponding source

On 2 May 2011 17:36, Devang Patel <dpatel at apple.com> wrote: > Here there is not any instruction (ignoring dbg intrinsics) with line number > information. If you add !dbg !7 at the end of 'ret' then it'll work. Hi Devang, Why does type/variable information depend on line information? cheers, --renato

On May 2, 2011, at 1:39 PM, Renato Golin wrote: > On 2 May 2011 17:36, Devang Patel <dpatel at apple.com> wrote: > Why does type/variable information depend on line information? You need line number information to map source code to instructions. Otherwise, you'll have a function and variable info in debug info but a debugger won't know which instructions belong to given

[ I discussed this briefly with Paul off list and he suggested it would be better here. ] Among the changes in 7.0.0 are some that were added to support DWARFv5's .debug_line. The presence of ".file" mutes debug info generated by the assembler as of r328208 - logic in AsmParser::enabledGenDwarfForAssembly(). The comment there states: "If we haven't encountered