similar to: [RFC][DWARF] Handling errors in DWARF .debug_line parsing

Hey James, This sounds really interesting. A few things that come to mind: - I'm curious what kind of errors you'd be okay with in dump mode but not in consumer mode. From LLDB's perspective, we probably want to extract as much information as possible from a malformed line table, as long as we don't end up lying of course. - I need to take another look at the code, but

On 16/12/2019 23:47, David Blaikie via llvm-dev wrote: > > > On Mon, Dec 16, 2019 at 2:40 PM Jonas Devlieghere <jonas at devlieghere.com > <mailto:jonas at devlieghere.com>> wrote: > > Hey James, > > This sounds really interesting. A few things that come to mind: > >  - I'm curious what kind of errors you'd be okay with in dump

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

Actually, MCJIT doesn't perform relocations on debug sections. I'm not sure that would matter anyway. The place where I'm handling the debug information is outside MCJIT and the MCJIT relocation code isn't really accessible at that point. Right now, when MCJIT emits an object image, it broadcasts an event to any registered listeners indicating that an object was emitted, passing

I'm working on adding source-based profiling support for MCJIT and in the process of implementing this, I came across a test case where an object is being generated that wants to have relocations applied to the .debug_line section. I see in the DebugInfo code that it currently only supports relocations applied to either the .debug_info or the .debug_info.dwo section. Can anyone give me an

That relocation handling is only done for the llvm-dwarfdump binary. MCJIT handles relocations a bit different. I think you just need to go ahead and allow the MCJIT relocation handling machinery to work on non-alloc sections and it should go ahead and handle these just fine, unless you're using the existing stuff in lib/DebugInfo to print out information or something? If this isn't what

On Thu, Jan 10, 2013 at 3:13 PM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > Actually, MCJIT doesn’t perform relocations on debug sections. I’m not > sure that would matter anyway. The place where I’m handling the debug > information is outside MCJIT and the MCJIT relocation code isn’t really > accessible at that point.**** > > ** > I know it doesn't,

Sorry, this is the attachment. 2014-02-19 15:08 GMT+08:00 杨勇勇 <triple.yang at gmail.com>: > Thank you. > > Here is an example and the attchment contains extra files including object > file and executable file. > I want to print for example the value of "a", but lldb command "frame > variable a" displays "0" and so does "b", and

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

All of this information is contained in the DWARF debug info that you must generate. Are you generating DWARF? If not, you will need to. If so, please attach an example program that contains DWARF and specify which function you are having trouble getting variable information for. Greg Clayton On Feb 18, 2014, at 12:44 AM, 杨勇勇 <triple.yang at gmail.com> wrote: > Hi, all > > I

Hi All, I see that llvm-readobj displays information similar to GNU readelf does except DWARF data. I also see llvm-dwarfdump dumps all DWARF data in user readable format. Is there a plan for readobj to incorporate similar options? This will make readobj more feature complete for reading objects similar to readelf. If this is not the plan, will llvm-dwarfdump be a tool that regular user

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

>> 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 (i.e. .cfi_*), which is >> cumbersome and misses a lot of things like actual DWARF encoding. >> 3. Using elf-dump and examining

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

>> > I'm fine with this as long as llvm-dwarfdump gets maintained. >> > >> >> I agree, and as I said in the original email, in the long term I >> believe llvm-dwarfdump is the correct solution. >> > > The problem is that if no one is working on testing these sorts of things > with llvm-dwarfdump then it won't be maintained for this

llvm[2]: Compiling DWARFDebugArangeSet.cpp for Debug+Asserts build llvm[2]: Compiling DWARFDebugAranges.cpp for Debug+Asserts build llvm[2]: Compiling DWARFDebugFrame.cpp for Debug+Asserts build /home/rkotler/llvm_trunk/lib/DebugInfo/DWARFDebugFrame.cpp:118:8: error: private field 'LinkedCIE' is not used [-Werror,-Wunused-private-field] CIE *LinkedCIE; ^ 1 error