search for: dwarf

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 bug in how line info sections are referred to from the DW_TAG_compile_unit DIE. I have run some basic tests, analyzed dumps of both the objects files and the final executables, and run a test progra...

I have recently been modifying the DWARF parser and have more patches planned and I want to be able to add unit tests that test the internal llvm DWARF APIs to ensure they continue to work and also validate the changes that I am making. There are not many DWARF unit tests other than very simple ones that test DWARF forms currently. I woul...

> On Nov 17, 2016, at 3:40 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Nov 17, 2016 at 3:12 PM Greg Clayton via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I have recently been modifying the DWARF parser and have more patches planned and I want to be able to add unit tests that test the internal llvm DWARF APIs to ensure they continue to work and also validate the changes that I am making. There are not many DWARF unit tests other than very simple ones that test DWARF forms currently. I woul...

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 some basic tests, analyzed dumps of both the objects files and the final executables, and run a test progra...

...> -----Original Message----- >> From: Greg Clayton [mailto:gclayton at apple.com] >> Sent: Thursday, November 17, 2016 5:01 PM >> To: David Blaikie >> Cc: llvm-dev at lists.llvm.org; Robinson, Paul; Eric Christopher; Adrian >> Prantl >> Subject: Re: [llvm-dev] DWARF Generator >> >> >>> On Nov 17, 2016, at 3:40 PM, David Blaikie <dblaikie at gmail.com> wrote: >>> >>> >>> >>> On Thu, Nov 17, 2016 at 3:12 PM Greg Clayton via llvm-dev <llvm- >> dev at lists.llvm.org> wrote: >>&gt...

On 18 October 2012 02:53, Robinson, Paul <Paul.Robinson at am.sony.com> wrote: > I had a "quality suite" at a previous job; it was the result of many PY > of effort. It was also debugger-based, which is a mixed blessing; you > get a lot of DWARF-parsing code for free, but then you get a lot of > debugger bugs for free too! And you don't get to test the DWARF > directly, you get to test how the debugger uses the DWARF. Not really > optimal, but still--a whole lot better than nothing. The trade off also goes in the other direc...

...- > >> From: Greg Clayton [mailto:gclayton at apple.com] > >> Sent: Thursday, November 17, 2016 5:01 PM > >> To: David Blaikie > >> Cc: llvm-dev at lists.llvm.org; Robinson, Paul; Eric Christopher; Adrian > >> Prantl > >> Subject: Re: [llvm-dev] DWARF Generator > >> > >> > >>> On Nov 17, 2016, at 3:40 PM, David Blaikie <dblaikie at gmail.com> wrote: > >>> > >>> > >>> > >>> On Thu, Nov 17, 2016 at 3:12 PM Greg Clayton via llvm-dev <llvm- > >> dev at li...

..... > DW_FORM_flag_present caused the problem. The old DW_FORM_flag works for us. I see this error from GDB 7.0 but GDB 7.2 is okay with it. Now you know as much as I do. :-) Eric Christopher wrote: > [in reply to what Renato Golin wrote:] > > With time, you might get to a point where Dwarf is a first-class > > citizen and there will be basic compatibility checks in "make check" > > and a build bot for GDB test suite on some platforms, but to get > > there, you'll go through a lot of pain. > > > > Hopefully not too much. Paul has been helpi...

Hi All, While working on some recent patches for x32 support, I ran into an unpleasant limitation the LLVM eco-system has with testing DWARF emission. We currently have several approaches, neither of which is great: 1. llvm-dwarfdump: the best approach when it works. But unfortunately lib/DebugInfo supports only a (small) subset of DWARF. Tricky sections like debug_frame aren't supported. 2. Relying of assembly directive emissions...

Renato, On Mar 17, 2011, at 2:00 PM, Renato Golin wrote: > On 17 March 2011 18:45, Devang Patel <dpatel at apple.com> wrote: >> Yes, It'd be good to have a setup to build SingleSource and MultiSource tests with debug info and run dwarfdump --verify on them. > > I tried some dwarfdump on a few examples I had and the comparison with > codesourcery's gcc is impossible, the resulting Dwarf is very > different. I did not mean comparing dwarfdump output. It is never going to work. Sorry for the confusion. I meant lett...

-- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161115/80fd3c17/attachment.html>

On 28 June 2012 10:15, Duncan Sands <baldrick at free.fr> wrote: >> I wanted to check that I'm headed in the right direction before I work more on >> LLVM debug info. What I'd like to do is update DIBuilder to expose exactly the >> facilities represented in modern DWARF, > > wouldn't it be better in the long term to make the debug info layer more > abstract rather than a direct mapping onto dwarf? And to have a Dwarf/COFF layers on top? -- cheers, --renato http://systemcall.org/

On 17 March 2011 21:54, Devang Patel <dpatel at apple.com> wrote: > I did not mean comparing dwarfdump output. It is never going to work. Sorry for the confusion. I meant letting dwarfdump verify the structure of dwarf info. Yes, using dwarfdump to verify is fine, but producing correct Dwarf is not the same as producing THE correct Dwarf you need. You still need some way of grepping for the sym...

Two functions in DwarfDebug, addBlockByrefAddress() and addComplexAddress(), contain this snippet of code: // Decode the original location, and use that as the start of the byref // variable's location. const TargetRegisterInfo *RI = Asm->TM.getRegisterInfo(); unsigned Reg = RI->getDwarfRegNum(Location...

On Fri, Jan 18, 2013 at 4:00 PM, Eli Bendersky <eliben at google.com> wrote: > Hi All, > > While working on some recent patches for x32 support, I ran into an > unpleasant limitation the LLVM eco-system has with testing DWARF > emission. We currently have several approaches, neither of which is > great: > > 1. llvm-dwarfdump: the best approach when it works. But unfortunately > lib/DebugInfo supports only a (small) subset of DWARF. Tricky sections > like debug_frame aren't supported. Could you poi...

In llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp, the compiler can emit a DW_AT_calling_convention attribute with a DW_TAG_class_type (and it looks like a DW_TAG_variant_part, DW_TAG_structure_type or DW_TAG_union_type as well), but the DWARF 4 specification says that DW_AT_calling_convention is not a valid attribute for any of those thre...

Thank you, Clayton. It works now! Our debugger server responds "name:J28;generic:fp;bitsize:32;encoding:uint;format:hex;gcc:60;dwarf:60". And I also set other "generic" attributes like sp, pc, ra, arg1~arg8 to related registers. I dig a little and find llvm dwarf generator uses TargetRegisterInfo::getFrameRegister() to obtain frame base, and uses TargetFrameLowering::getFrameIndexReference() to obtain frame base...

...lready platform specific, I'm leaning towards saying that the way to add platform specific atom attributes is to add a Reference with no target to the Atom with a Kind field that for that platform means whatever attribute you need. > >> >>> 5) are you planning to support dwarf information too ? >> Debugging information is another big open question. The dwarf format is very much tied to the section model. Not only is the debug information put is sections with special names, but the dwarf debug into references code by its address in the .o files (the Atom model doe...

...Feb 5, 2016, at 3:17 PM, Peter Collingbourne via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > Hi all, > > > > We have profiled [1] the memory usage in LLVM when LTO'ing Chromium, and > > we've found that one of the top consumers of memory is the DWARF emitter in > > lib/CodeGen/AsmPrinter/Dwarf*. > > I'm staring at the profile attached to the post #15 on the link you posted, can you confirm that the Dwarf emitter accounts for 6.7%+15.6%=22.3% of the the total allocated memory? > If I understand correctly the numbers, this doe...

...e 2012 10:15, Duncan Sands <baldrick at free.fr> wrote: >>> I wanted to check that I'm headed in the right direction before I work more on >>> LLVM debug info. What I'd like to do is update DIBuilder to expose exactly the >>> facilities represented in modern DWARF, >> >> wouldn't it be better in the long term to make the debug info layer more >> abstract rather than a direct mapping onto dwarf? > > And to have a Dwarf/COFF layers on top? And have the code generators output the appropriate dwarf or whatever. Ciao, Duncan.