search for: dicontext

I just updated from the most recent svn ToT. I'm now getting the following compilation errors. Looks like DIIContext.h needs some includes. Does anyone else see this error also? Am I missing something? In file included from DIContext.cpp:10: /extra/xguo/workspace/llvm/include/llvm/DebugInfo/DIContext.h:27: error: 'uint32_t' does not name a type /extra/xguo/workspace/llvm/include/llvm/DebugInfo/DIContext.h:28: error: 'uint32_t' does not name a type /extra/xguo/workspace/llvm/include/llvm/DebugInfo/DIContext.h:30:...

...15:24, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote: > I just updated from the most recent svn ToT. I'm now getting the following compilation errors. Looks like DIIContext.h needs some includes. Does anyone else see this error also? Am I missing something? > > In file included from DIContext.cpp:10: > /extra/xguo/workspace/llvm/include/llvm/DebugInfo/DIContext.h:27: error: 'uint32_t' does not name a type > /extra/xguo/workspace/llvm/include/llvm/DebugInfo/DIContext.h:28: error: 'uint32_t' does not name a type > /extra/xguo/workspace/llvm/include/llvm/DebugInfo/...

...then incremental on top of it. Thoughts? -eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121105/83c23e1d/attachment.html> -------------- next part -------------- diff --git a/include/llvm/DebugInfo/DIContext.h b/include/llvm/DebugInfo/DIContext.h index 8d6054a..e6fa54d 100644 --- a/include/llvm/DebugInfo/DIContext.h +++ b/include/llvm/DebugInfo/DIContext.h @@ -15,6 +15,7 @@ #ifndef LLVM_DEBUGINFO_DICONTEXT_H #define LLVM_DEBUGINFO_DICONTEXT_H +#include "llvm/ADT/DenseMap.h" #include &quo...

On Mon, Nov 5, 2012 at 5:17 PM, Eric Christopher <echristo at gmail.com> wrote: > For llvm-dwarfdump we need to handle relocations inside the debug info > sections in order to successfully dump the dwarf info including strings. > Nick sent out a partial patch that did this not too long ago and I've taken > it and gone in a bit of a different direction, but kept the same basic

Hi, I would like to extend DebugInfo library for the purpose of using it in AddressSanitizer/ThreadSanitizer run-time libraries. Current interface is: class DILineInfo { const char *FileName; uint32_t Line; uint32_t Column; ... }; class DIContext { ... virtual DILineInfo getLineInfoForAddress(uint64_t address) = 0; }; First, I would like to get function name associated with the address. Then, I would like to get inlined frames as well. Then, I would like to be able to get the same info about global variables. Finally, I would like to r...

...of using it in > AddressSanitizer/ThreadSanitizer run-time libraries. > > > > Current interface is: > > > > class DILineInfo { > > const char *FileName; > > uint32_t Line; > > uint32_t Column; > > ... > > }; > > > > class DIContext { > > ... > > virtual DILineInfo getLineInfoForAddress(uint64_t address) = 0; > > }; > > > > First, I would like to get function name associated with the address. > > Then, I would like to get inlined frames as well. > > Then, I would like to be able to...

...here, which is that basically in the short term, I think it makes the most sense to keep them separate. In the future, if / when we decide to provide a unified interface (e.g libDebugInfo as you suggest), there will be additional machinery required to wrap the two interfaces, so we could move the DIContext class at that time. Does this make sense? On Thu Jan 29 2015 at 10:54:37 AM Frédéric Riss <friss at apple.com> wrote: > On Jan 29, 2015, at 10:20 AM, Zachary Turner <zturner at google.com> wrote: > > I've been working on adding pdb reading support to llvm. This started...

...I would like to extend DebugInfo library for the purpose of using it in AddressSanitizer/ThreadSanitizer run-time libraries. > > Current interface is: > > class DILineInfo { > const char *FileName; > uint32_t Line; > uint32_t Column; > ... > }; > > class DIContext { > ... > virtual DILineInfo getLineInfoForAddress(uint64_t address) = 0; > }; > > First, I would like to get function name associated with the address. > Then, I would like to get inlined frames as well. > Then, I would like to be able to get the same info about global va...

...rpose of using it in AddressSanitizer/ThreadSanitizer run-time libraries. > > > > Current interface is: > > > > class DILineInfo { > > const char *FileName; > > uint32_t Line; > > uint32_t Column; > > ... > > }; > > > > class DIContext { > > ... > > virtual DILineInfo getLineInfoForAddress(uint64_t address) = 0; > > }; > > > > First, I would like to get function name associated with the address. > > Then, I would like to get inlined frames as well. > > Then, I would like to be able to...

...all of the code in lib/DebugInfo to lib/DebugInfo/dwarf, and then make another folder called lib/DebugInfo/pdb. These would then be compiled into two separate libraries. so you would have libDebugInfoDWARF and libDebugInfoPDB. Would you still have libDebugInfo at all? I ask because there is the DIContext abstraction that’s not tied to a particular debug format (It’s used by llvm-symbolizer, and I guess you have some interest in having that working on windows PDB files). But DIContext.cpp as one method, thus having a library for just that might be really overkill. > Another approach is to just p...

...here, which is that basically in the short term, I think it makes the most sense to keep them separate. In the future, if / when we decide to provide a unified interface (e.g libDebugInfo as you suggest), there will be additional machinery required to wrap the two interfaces, so we could move the DIContext class at that time. > > Does this make sense? Sure, no objection to moving files around :-) Out of curiosity, if the only target users of the library are the dump tool and lldb, why put the code in LLVM and not only in LLDB? I would love to see LLDB using our Dwarf parser because there is...

...-dev < cfe-dev at lists.llvm.org> wrote: > 2. Will LLD and LLDB be updated as necessary to support CodeView? > Rui is is looking at making LLD link codeview from object files into PDBs. Zachary Turner intends to add PDB reading support to LLDB. We already have a PDB implementation of DIContext in lib/DebugInfo that uses PDBs. The only client is currently llvm-symbolizer, but the idea was that LLDB could use it, and eventually we should shift it off DIA and over to something cross-platform. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ll...

...p;view=rev >> Log: >> Initial support for DWARF CFI parsing and dumping in LLVM >> >> Added: >> llvm/trunk/lib/DebugInfo/DWARFDebugFrame.cpp >> llvm/trunk/lib/DebugInfo/DWARFDebugFrame.h >> Modified: >> llvm/trunk/include/llvm/DebugInfo/DIContext.h >> llvm/trunk/include/llvm/Support/Dwarf.h >> llvm/trunk/lib/DebugInfo/DWARFContext.cpp >> llvm/trunk/lib/DebugInfo/DWARFContext.h >> llvm/trunk/tools/llvm-dwarfdump/llvm-dwarfdump.cpp >> >> Modified: llvm/trunk/include/llvm/DebugInfo/DICont...

Hi, I've built the llvm-dwarfdump tool from the 3.3 branch and ran it on simple binary compiled with dwarf4 debug information. The tool seem to read the file correctly including dwarf information (DIContext::getDWARFContext returns a valid context), but when trying to access line information, all I get is "<invalid>" string for the file name and 0's for line and column information. I've seen that there was a talk in the recent Europoe lldb-dev meeting but couldn't figure o...

> I've built the llvm-dwarfdump tool from the 3.3 branch and ran it on simple > binary compiled with dwarf4 debug information. > > > > The tool seem to read the file correctly including dwarf information > (DIContext::getDWARFContext returns a valid context), but when trying to > access line information, all I get is "<invalid>" string for the file name > and 0's for line and column information. > > > > I've seen that there was a talk in the recent Europoe lldb-dev meet...

I've been working on adding pdb reading support to llvm. This started as a tool for dumping info from a pdb (similar to llvm-dwarfdump), which has been checked in and currently has limited support for dumping pdb. There's still more to be done on the pdb dumping tool, but at this point -- to reduce duplicated effort -- I think it makes the most sense to start moving some of this logic

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

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

...using NotifyLoadedFtor = std::function<void(ObjHandleT, const ObjectPtr &Obj,                                               const LoadedObjectInfo &)>;                                                     ^^^^^^^^^^^^^^^^ It refers to llvm::LoadedObjectInfo base class in llvm/DebugInfo/DIContext.h instead of   llvm::RuntimeDyld::LoadedObjectInfo in llvm/ExecutionEngine/RuntimeDyld.h I think it should actually use the derived RuntimeDyld::LoadedObjectInfo, as this is what listeners expect: $ grep -h -r -A 1 "NotifyObjectEmitted(" ./include/llvm/ExecutionEngine/JITEventListener.h...

...bolizer that would be used in AddressSanitizer (ASan) and ThreadSanitizer (TSan) tools which are now part of projects/compiler-rt (as a first step, symbolizer should be able to return file/line info for a given address). I'd like to use and gradually extend the interface in "llvm/DebugInfo/DIContext.h" I see two obstacles: 1) How can I include LLVM headers in source files inside projects/compiler-rt? As a local workaround, I modify configuration for ASan/TSan runtimes as follows: CFLAGS.asan-x86_64 := $(CFLAGS) -I$(PathToLLVMInclude) -I$(PathToLLVMBuildInclude) Note that I need both &quo...