search for: libdebuginfo

...ew tool through big internal validation campaigns during which the llvm powered dsymutil output would be compared to the system’s dsymutil one. This is also the reason we aim for bit-for-bit compatibility. The current plan is to host the code in the llvm repository. dsymutil will make heavy use of libDebugInfo and won’t share anything with the lld codebase (The underlying concepts are just too different). It’s also not clear yet where most of the implementation logic will end up. I expect most of the core logic to be in tools/dsymutil, but some of it might be better folded directly into libDebugInfo. So...

-- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161115/80fd3c17/attachment.html>

...aigns during >> which the llvm powered dsymutil output would be compared to the system’s >> dsymutil one. This is also the reason we aim for bit-for-bit compatibility. >> >> The current plan is to host the code in the llvm repository. dsymutil >> will make heavy use of libDebugInfo and won’t share anything with the lld >> codebase (The underlying concepts are just too different). It’s also not >> clear yet where most of the implementation logic will end up. I expect most >> of the core logic to be in tools/dsymutil, but some of it might be better >> fo...

See my earlier response to Adrian. But I'll rehash the point 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 &l...

...g internal validation campaigns during which the llvm powered dsymutil output would be compared to the system’s dsymutil one. This is also the reason we aim for bit-for-bit compatibility. >> >> The current plan is to host the code in the llvm repository. dsymutil will make heavy use of libDebugInfo and won’t share anything with the lld codebase (The underlying concepts are just too different). It’s also not clear yet where most of the implementation logic will end up. I expect most of the core logic to be in tools/dsymutil, but some of it might be better folded directly into libDebugInfo. &gt...

...ry Turner <zturner at google.com> wrote: > > See my earlier response to Adrian. But I'll rehash the point 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 an...

...ation with the target DIE’s name - DWARF expression pretty-printing With these enhancements, the debug_info dump is nearly always sufficient and the user rarely needs to go and decode himself the referenced content of other debug sections. There will be more work by me going on in llvm-dwarfdump/libDebugInfo these coming weeks. I’ll start sending patches to llvm-commits later today. Cheers, Fred

...t in LLDB for reading PDBs while debugging on Windows. > > I think the best way to do this is to move 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...

In ELF .o files with debug info, there are relocations applied to the DWARF sections. For example, when emitting offsets into the stringpool, we emit a relocation. How should we support this? llvm-dwarfdump currently works by finding the relevant dwarf sections and passing them in to lib/DebugInfo. The relocations can be iterated over in lib/Object using the relocation_iterator. Should dwarfdump

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

On Aug 16, 2012, at 8:51 AM, Alexey Samsonov <samsonov at google.com> wrote: > I have a very raw prototype of such a binary, that uses LLVM's libObject, libSupport, libDebugInfo, and is integrated into ASan, which fork+execs it > when it needs to symbolize a stack trace. It successfully symbolizes ASan report for model Chromium crash. If Chromium is build with -gline-tables-only (500Mb), > it runs in less than a second (most time is spent on loading the binary in mem...

Hi I'm using llvm-5. Browsing the source of llvm-dwarfdump and trying it on some shared libraries, I see I can print the debug info (assuming it exists). For some function, I'm wondering if there's a short cut to prettyprinting the signature of a function in the library? I think, looking at the output, that enough information exists but it seems to involve looking at the subprogram

Hi, This is my first post to this list, so I apologize in advance if I mess up on any list etiquette. Jumping right in, I’m making use of the DebugInfo/DWARF APIs to get debugging information out of binaries (what else!). One of the bits of data I need is the location information stored in the location list section as well as inline in DW_AT_location attributes and similar. So far I’ve succeeded

...o abstraction (see DIContext). This abstraction is used by llvm-symbolizer and other tools to access the DWARF (mostly (only?) line tables) data through a generic interface, but it might make the interface look a bit strange if you look at it from a pure DWARF point-of-view. > - Apart from that libDebugInfo has been used nearly exclusively to power llvm-dwarfdump. Functionality > might be absent/hidden because nobody has come up with a use-case for it. > >> Unfortunately, I’m stopped here. As far as I can tell, there is no implementation of a DWARF expression parser, per §2.5 of the DW...

> On Nov 7, 2014, at 10:07 AM, Shankar Easwaran <shankare at codeaurora.org> wrote: > > Thanks for your reply, Fred. > > It might work better, if its in a form of an API. So that the linker could call an API instead of running a tool ? Yes, the long term goal would be to expose it as an API. The separate tool is just a first step. I can’t give you the exact shape of the API

...ng with the toolchain gives you things you can’t really get otherwise. Valgrind is still great as a self-standing thing. > > Not sure that's quite the same though - with sanitizer integrating with the optimizers is the key here. > > With bloaty - it could, at worst, use LLVM's libDebugInfo as a library to implement the more advanced debug-using features without being less functional than an in-LLVM implementation. I’m a bit biased too, but fwiw: my preference would be to add a new size analysis tool to llvm. Such a tool might grow to depend on code for object file parsing, debug in...

On Thu, Jun 21, 2012 at 12:52 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Thu, Jun 21, 2012 at 1:42 AM, Kostya Serebryany <kcc at google.com> wrote: > >> Can we alter the build system so that when building a run-time library it >> modifies all .cpp files like this: >> namespace FOO { >> <file body> >> } >> This

> On Oct 1, 2018, at 3:16 PM, David Blaikie <dblaikie at gmail.com> wrote: > > (my vote, somewhat biased - is that I'd love to see more investment in Bloaty (to keep all these sort of size analysis tools and tricks in one place), but sort of accept folks are probably going to keep building more infrastructure for this sort of thing in LLVM directly) I get where that comes

(resurrecting the thread, as much is discussed here already) Formulating Kostya's suggestion: What do you think of compiling LLVM sources into ASan/TSan runtime by just taking the library sources, providing custom compiler (target) flags *and* a flag "-Dllvm=__sanitizer_llvm"? Yeah, it's hacky and applicable to LLVM libs, but OTOH we don't plan to use smth else for now (in

Hi llvm-dev, I've been implementing a tool for analysing XRay traces. A recap of XRay's original RFC [0] mentions a tool that does function call accounting as a starting point. This is implemented currently in D21987 [1], and is being reviewed by David Blaikie. One key issue in that review is the dependency between the log format determined by the XRay runtime implementation in