search for: libdwarf

...r 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 variables. The particular libdwarf API queries the ".debug_pubnames" This code is no longer functional because my LLVM generated executables do not seem to have the .debug_pubnames sections. From the discussion I did not gather that the sections would be removed comple...

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: <http://lists.llvm.org/pipermail/llvm...

...t 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 variables. The particular libdwarf API queries the > ".debug_pubnames" This code is no longer functional because my LLVM > generated executables do not seem to have the .debug_pubnames sections. From > the discussion I did not gather that the sections wou...

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 ? - Devang

...ed > by default. What are you doing that involves looking for global > variables in the pubnames > section? > Thanks for the information. After I sent out the email, I saw the patch you reverted on viewVC. I have some proprietary code that looks at the debug info in an executable using libdwarf; It queries the debug info on demand with a variable name and uses dwarf_get_globals which, I believe, uses .debug_pubnames. I believe you made only one change to take out support for this section, right ? I will revert that change and give it a go. Thanks, Pranav Qualcomm Innovation Center, Inc....

...orms to the current command line interface? I could easily create a separate command line parser for Darwin that mimicks Darwin dwarfdump (like llvm-objdump does), or we could just change the command line interface for llvm-dwarfdump. I know that there is also a dwarfdump utility on Linux (based on libdwarf?) that has an entirely different command line interface from both llvm-dwarfdump and Darwin dwarfdump. Do people see value in keeping the llvm-dwarfdump command line interface or would changing it to the above format be acceptable? thanks for your input! Adrian

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 code locations, it becomes clear that they are not very "useful". Consider the following small example (C++): 1: #include <iostream>...

...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 (extracted from the DWARF line table) with the corresponding source code locations, it becomes clear that they are not very "useful". > > Consider the following small example (C++): > 1: #include <iostrea...

...gt;> 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 code locations, it becomes >> clear that they are not very "useful". >> >> Consider the following small example...

...rote: >> >>> 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 code locations, it becomes clear that they are not very "useful". >>> >>> Consider the following small example (C++): >>>...

Thank you Frits! I noticed the following lines in the dwarf output (run with -O2): .uleb128 40 # Offset .byte 134 # DW_CFA_offset + Reg (6) .uleb128 4 # Offset .byte 135 # DW_CFA_offset + Reg (7) .uleb128 3 # Offset .byte 131 # DW_CFA_offset + Reg (3)

...;>> 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 code locations, it >>>> becomes clear that they are not very "useful". >>>> >>>&...

...ried David Anderson's dwarfdump (after Paul pointed it out to > me), but as far as I can tell, it has no support from printing out the > .debug_names section (the print_debug_names function is stubbed out). > **I think** I got the correct source repository > (git://git.code.sf.net/p/libdwarf/code) as the last commit there is > dated yesterday. > > > For testing on the lldb side I have been deliberately trying to avoid > adding another dimensions to the ever-growing test matrix. I don't > think this functionality is worth it, especially not if you view the > t...

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

> 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

...of its container, FDEs have fields with size being "target address size", >> + // which isn't specified in DWARF in general. It's only specified for CUs, but >> + // .eh_frame can appear without a .debug_info section. Follow the example of >> + // other tools (libdwarf) and extract this from the container (ObjectFile >> + // provides this information). This problem is fixed in DWARFv4 >> + // See this dwarf-discuss discussion for more details: >> + // http://lists.dwarfstd.org/htdig.cgi/dwarf-discuss-dwarfstd.org/2011-December/001173.html &gt...