similar to: [RFC] llvm-dwarfdump's command line interface

On Fri, Sep 8, 2017 at 2:32 PM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On Fri, Sep 8, 2017 at 2:25 PM Adrian Prantl <aprantl at apple.com> wrote: >> >> 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

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 ? Thank you, Damien -------------- next part -------------- An HTML attachment was scrubbed... URL:

> On Jun 14, 2018, at 7:01 AM, Pavel Labath via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Thank you all. I am going to try to reply to all comments in a single email. > > Regarding the .apple_objc idea, I am afraid the situation is not as > simple as just flipping a switch. Jonas is currently working on adding the support for DWARF5-style Objective-C accelerator

> On Jun 13, 2018, at 11:18 AM, Jonas Devlieghere via lldb-dev <lldb-dev at lists.llvm.org> wrote: > > Hi Pavel, > >> On Jun 13, 2018, at 6:56 AM, Pavel Labath <labath at google.com <mailto:labath at google.com>> wrote: >> >> Hello again, >> >> It's been nearly six months since my first email, so it's a good time >> to

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

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

Hello Csaba, Thanks for the heads up. I am the one who wrote that test. I'll look into that shortly. Sorry about the trouble. pl On Mon, 16 Apr 2018 at 11:56, Csaba Raduly via llvm-dev < llvm-dev at lists.llvm.org> wrote: > ******************** > FAIL: LLVM :: tools/llvm-dwarfdump/X86/debug-names-find.s (38881 of 41794) > ******************** TEST 'LLVM :: >

******************** FAIL: LLVM :: tools/llvm-dwarfdump/X86/debug-names-find.s (38881 of 41794) ******************** TEST 'LLVM :: tools/llvm-dwarfdump/X86/debug-names-find.s' FAILED ******************** Script: -- /home/csabaraduly/wk/LLVM/build_release/bin/llvm-mc -triple x86_64-pc-linux /home/csabaraduly/wk/LLVM/llvm/test/tools/llvm-dwarfdump/X86/debug-names-find.s -filetype=obj -o

r330121 should fix that. Let me know if you still run into any issues. cheers, pl On Mon, 16 Apr 2018 at 12:07, Pavel Labath <labath at google.com> wrote: > Hello Csaba, > Thanks for the heads up. I am the one who wrote that test. I'll look into > that shortly. Sorry about the trouble. > pl > On Mon, 16 Apr 2018 at 11:56, Csaba Raduly via llvm-dev < > llvm-dev at

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 Feb 11, 2013, at 18:13, Eli Bendersky <eliben at google.com> wrote: > On Thu, Feb 7, 2013 at 2:50 PM, Erik Verbruggen <erikjv at me.com> wrote: >> Hi, >> >> I noticed that llvm-dwarfdump does not show any information about the eh_frame section. While DWARFContext::getDebugAranges explicitly tries to parse it, it fails because the DWARFContextInMemory

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

Hi, [ I think I put the most important contributors to the DebugInfo stuff in Cc:. Is there anyone else that I am missing? ] Just a short notice that I am currently working on making llvm-dwarfdump more developer friendly. There are quite a few features in Darwin’s dwarfdump that we find quite useful and that we would like to contribute to llvm-dwarfdump. I have started by augmenting the

On Wed, 17 Jan 2018 17:13:36 +0100, Pavel Labath via lldb-dev wrote: > so I'm writing this email to see if there's anyone > else interested in this topic, and to try to synchronize our efforts. I am sure interested in DWARF-5 .debug_names. I wrote its producer+consumer for GDB (but not producing/using DW_IDX_DIE_offset as GDB cannot use it). > 1. add .debug_names support to

Hi, I noticed that llvm-dwarfdump does not show any information about the eh_frame section. While DWARFContext::getDebugAranges explicitly tries to parse it, it fails because the DWARFContextInMemory constructor does not check for that specific section name. A fix would be to check wether the name is "debug_frame" or "eh_frame". If this is correct, should I submit a smallish

On Thu, Feb 7, 2013 at 2:50 PM, Erik Verbruggen <erikjv at me.com> wrote: > Hi, > > I noticed that llvm-dwarfdump does not show any information about the eh_frame section. While DWARFContext::getDebugAranges explicitly tries to parse it, it fails because the DWARFContextInMemory constructor does not check for that specific section name. A fix would be to check wether the name is

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

> On Jan 19, 2015, at 10:26 AM, Adrian Prantl <aprantl at apple.com> wrote: > > >> On Jan 19, 2015, at 10:08 AM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> Hey guys, >> >> Frederic is introducing the expression dumping support and in the interests of tersity is skipping the "DW_" in every

Hear hear. DW_ adds no readability but AT_/TAG_/OP_/etc do. Dropping the FORM entirely is fine; I view that as a mechanical encoding thing, not relevant to the informational content. If you're debugging the encoding then it would matter, but for a random string-value attribute it really doesn't matter which of the 3 (4?) different forms was used as long as the actual string shows up