search for: dilineinfospecifi

...oint in the > future, but this is out of scope for now). Instead, we save whatever we > want displayed in AT_name, but there's no way to access that with the > public API (it works nicely in gdb/lldb though). > Alright, I see why it makes sense. We can pass this information through DILineInfoSpecifier. In fact, probably it makes sense to change the layout of this structure: there would be 3 types of file/line info (None, Regular, AbsoluteFilePath). (though, probably we may make latter the default) and 3 types of function name info (None, Name, LinkageName). > > > On Wed, May 7, 2014...

...is only returned as a fallback in `DWARFDebugInfoEntryMinimal::getSubroutineName` when the linkage name is not available [2]. If this is not currently possible, is there any interest in adding such access to the public DebugInfo API? Perhaps with an additional "UnmangledName" option in `DILineInfoSpecifier`. Thanks, Isaiah [1]: for example: 0x0001bb00: DW_TAG_subprogram [2] DW_AT_MIPS_linkage_name [DW_FORM_strp] ( .debug_str[0x00007934] = "julia_vcat4473") DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000913] = "vcat") [2] https://githu...

...yMinimal::getSubroutineName` when the linkage name is > not > > available [2]. > > > > If this is not currently possible, is there any interest in adding such > > access to the public DebugInfo API? Perhaps with an additional > > "UnmangledName" option in `DILineInfoSpecifier`. > > > > Thanks, > > Isaiah > > > > [1]: for example: > > > > 0x0001bb00: DW_TAG_subprogram [2] > > DW_AT_MIPS_linkage_name [DW_FORM_strp] ( > > .debug_str[0x00007934] = "julia_vcat4473") > >...

...t;>>> > > >>>> > If this is not currently possible, is there any interest in adding > >>>> > such > >>>> > access to the public DebugInfo API? Perhaps with an additional > >>>> > "UnmangledName" option in `DILineInfoSpecifier`. > >>>> > > >>>> > Thanks, > >>>> > Isaiah > >>>> > > >>>> > [1]: for example: > >>>> > > >>>> > 0x0001bb00: DW_TAG_subprogram [2] > >>>> >...

...me >>> is not >>> > available [2]. >>> > >>> > If this is not currently possible, is there any interest in adding such >>> > access to the public DebugInfo API? Perhaps with an additional >>> > "UnmangledName" option in `DILineInfoSpecifier`. >>> > >>> > Thanks, >>> > Isaiah >>> > >>> > [1]: for example: >>> > >>> > 0x0001bb00: DW_TAG_subprogram [2] >>> > DW_AT_MIPS_linkage_name [DW_FORM_strp] ( >>> > .debug...

...sLittleEndian, const RelocAddrMap &Map) : + IsLittleEndian(isLittleEndian), RelocMap(Map) {} public: virtual void dump(raw_ostream &OS); + /// Get the number of compile units in this context. unsigned getNumCompileUnits() { if (CUs.empty()) @@ -70,6 +73,7 @@ public: DILineInfoSpecifier Specifier = DILineInfoSpecifier()); bool isLittleEndian() const { return IsLittleEndian; } + const RelocAddrMap &relocMap() const { return RelocMap; } virtual StringRef getInfoSection() = 0; virtual StringRef getAbbrevSection() = 0; @@ -108,8 +112,9 @@ public:...

...st DWARFDebugFrame *getDebugFrame(); >> + >> /// Get a pointer to a parsed line table corresponding to a compile unit. >> const DWARFDebugLine::LineTable * >> getLineTableForCompileUnit(DWARFCompileUnit *cu); >> @@ -96,11 +101,13 @@ public: >> DILineInfoSpecifier Specifier = DILineInfoSpecifier()); >> >> virtual bool isLittleEndian() const = 0; >> + virtual uint8_t getAddressSize() const = 0; >> virtual const RelocAddrMap &infoRelocMap() const = 0; >> virtual const RelocAddrMap &lineRelocMap() const = 0;...

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

..." > +#include "llvm/Support/FileSystem.h" > +#include "llvm/Support/Mutex.h" > +#include "llvm/Support/MutexGuard.h" > +#include "llvm/Support/raw_ostream.h" > + > +using namespace llvm; > +using namespace llvm::object; > +typedef DILineInfoSpecifier::FileLineInfoKind FileLineInfoKind; > + > +namespace { > + > +// language identifier (XXX: should we generate something better from debug info?) > +#define JIT_LANG "llvm-IR" > +#define LLVM_PERF_JIT_MAGIC ((uint32_t) 'J' << 24 | (uint32_t) 'i' &l...

Having something like this available in tree would definitely be useful. For simplicity, why don't we start with support for the second style? This is the long term useful one and would be a good starting point for getting the code in tree. Can you give a pointer to the patch so that I can assess the rough complexity? If it's simple enough, I'd be happy to help get it reviewed

Hi, On 2016-12-29 13:17:50 -0800, Philip Reames wrote: > Having something like this available in tree would definitely be > useful. Cool. > For simplicity, why don't we start with support for the second style? This > is the long term useful one and would be a good starting point for getting > the code in tree. Works for me. > Can you give a pointer to the patch so that