similar to: [LLVMdev] Parsing dwarf debug info of an GAS assembly file

On Mar 9, 2011, at 6:32 PM, Damien Vincent wrote: > > I have a question not strictly related to LLVM: > I know there is a tool (libdwarf / dwarfdump) to dump/parse debug information of an object file, > but do you know a tool that can parse dwarf sections of a ".s" GAS assembly file ? I do not know any tool other than the assembler itself. What are you trying to do ? -

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 31.05.2011 19:22, Devang Patel wrote: > > On May 30, 2011, at 11:11 AM, trash-stuff at gmx.de > <mailto:trash-stuff at gmx.de> wrote: > >> 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

On May 30, 2011, at 11:11 AM, trash-stuff at gmx.de wrote: > 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

On May 31, 2011, at 10:36 AM, trash-stuff at gmx.de wrote: > On 31.05.2011 19:22, Devang Patel wrote: >> >> >> On May 30, 2011, at 11:11 AM, trash-stuff at gmx.de wrote: >> >>> 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

Hi All, I just enabled the generation of dwarf debugging information for Hexagon. It did not require much save for the setting of a flag in MCAsmInfo. However, now I see that the ".debug_pubnames" sections is not generated. I did read discussion about the section not really being useful for debuggers in terms of accelerated access, but I have code that uses libdwarf to check for global

On 31.05.2011 19:45, Devang Patel wrote: > > On May 31, 2011, at 10:36 AM, trash-stuff at gmx.de > <mailto:trash-stuff at gmx.de> wrote: > >> On 31.05.2011 19:22, Devang Patel wrote: >>> >>> On May 30, 2011, at 11:11 AM,trash-stuff at gmx.de >>> <mailto:trash-stuff at gmx.de>wrote: >>> >>>> Hi all, >>>>

On Mar 8, 2012, at 2:29 PM, Pranav Bhandarkar wrote: > Hi All, > > I just enabled the generation of dwarf debugging information for Hexagon. It > did not require much save for the setting of a flag in MCAsmInfo. > > However, now I see that the ".debug_pubnames" sections is not generated. I > did read discussion about the section not really being useful for

I would like to grow llvm-dwarfdump to become a drop-in replacement for the dwarfdump utility that is currently shipping on Darwin. (You can search the web for "darwin dwarfdump manpage" to see the currently supported feature set.) Doing this means implementing the missing features, such as the ability to print only subsets of DIEs, looking up DIEs by name or address, and the option to

Hi Eric, > Nope, it's removed completely. No debugger that I know of uses it at > all and it's > useless for many reasons. Adding the code back in to generate it is > possible (it's > a fairly small commit that's easily reverted), but I see no reason to > have it generated > by default. What are you doing that involves looking for global > variables in the

On Mar 17, 2011, at 8:44 AM, Renato Golin wrote: >> dwarfdump --verify will do this. > > Is this being used in LLVM tests? This is an idea. It is not used in llvm/test tests. > I had a look at your debug tests in clang and they're similar to what I do here. > > The problem with debug tests is that it doesn't depend only on the > compiler, but on the debugger

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. For instance, GCC declares the types at

sun created this tag for identifying functions that dumped their register arguments onto the stack. this is enough for llvm-dwarfdump to recognise and print the attribute. hopefully someone will commit it. cheers, dlg Index: include/llvm/Support/Dwarf.def =================================================================== --- include/llvm/Support/Dwarf.def (revision 301500) +++

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

Could dwarfdump --verify be used to check the debug info? - Jan ________________________________ From: Devang Patel <dpatel at apple.com> To: Talin <viridia at gmail.com> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> Sent: Thu, March 17, 2011 9:41:10 AM Subject: Re: [LLVMdev] Writing unit tests for DWARF? Talin, If there is a magic wand, I would be interested

On Mar 17, 2011, at 7:29 AM, Renato Golin wrote: > On 17 March 2011 13:48, Devang Patel <dpatel at apple.com> wrote: >> I think you are mistaken here. I maintain and support debug info for two front ends (llvm-gcc and clang). Go ahead and check svn archives for last one year and see how many times I had to update llvm-gcc FE. > > Hi Devang, > > First, I'm not

On Tue, Nov 9, 2010 at 9:04 AM, Devang Patel <dpatel at apple.com> wrote: > > > On Nov 8, 2010, at 10:52 PM, Talin <viridia at gmail.com> wrote: > > On Mon, Nov 8, 2010 at 9:56 AM, Devang Patel < <dpatel at apple.com> > dpatel at apple.com> wrote: > >> >> On Nov 6, 2010, at 7:35 PM, Talin wrote: >> >> After to speaking to Devang

Talin, If there is a magic wand, I would be interested to know! DIDescriptor.Verify() is not suitable for you needs. It checks structure of encoded debug info after optimizer has modified the IR. Its main goal is inform Dwarf writer, at the end of code gen, which IR construct it should ignore. If you want to test code gen you have to link compiled code and run it regularly. That's what

Talin, You're developing your own language and tool sets, it brings fresh perspective in our predominately C orientated environment, which is good. On Apr 1, 2011, at 8:12 PM, Talin wrote: > Is this a limitation of DWARF or of the LLVM generator? Neither, IMO. My own reading of DWARF did not find clear wording on this subject. I am not even sure if it is just a darwin gdb implementation

One problem that has been vexing me of late: It seems that whenever I run into a problem that requires debugging one of my programs in gdb, before I can do that I have to fix my frontend's broken generation of debugging info. The code that generates debugging information is quite fragile - you have to generate metadata for each of your files, classes, and functions, and do so without error,