similar to: [LLVMdev] [PATCH] basic reading reloc visitor for x86_64 ELF

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

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

On 06.11.2020 13:32, James Henderson wrote: > Hi Alexey, > > On Thu, 5 Nov 2020 at 21:02, Alexey Lapshin <avl.lapshin at gmail.com > <mailto:avl.lapshin at gmail.com>> wrote: > > Hi James, > > On 05.11.2020 17:59, James Henderson wrote: >> (Resending with history trimmed to avoid it getting stuck in >> moderator queue). >>

Hi Jack, Everything should be already using the sized Emit* routines directly rather than outputting individual bytes of larger entities piecemeal. Have you found that not to be the case? The Emit* routines handle endianness for you, so you shouldn't have to do much beyond that. For example, here's the EmitInvValue() implementation that underlies things and does the endianness transform:

Hi Jack, I would have expected the Mips backend to be using these routines (or more likely something on top of them) to emit the contents of the data and text sections and thus have the bit-twiddling done by these routines. I take it that's not happening? Basically, this should already work without any additional infrastructure. If it's not, something is broken and bypassing the

Jim, I see routines that are already available to do the endianizing, but the data and text section contents don't have sizing for the individual elements as far as I can see so that I can endianize them. That is the part I am trying to solve, not the bit twiddling algorithm. Did I miss something? Jack ________________________________________ From: Jim Grosbach [grosbach at apple.com] Sent:

Hi, In the document: http://llvm.org/docs/WritingAnLLVMBackend.html described example like: SparcTargetAsmInfo::SparcTargetAsmInfo(const SparcTargetMachine &TM) { Data16bitsDirective = "\t.half\t"; Data32bitsDirective = "\t.word\t"; Data64bitsDirective = 0; // .xword is only supported by V9. ZeroDirective = "\t.skip\t"; CommentString = "!";

At a guess that looks like your llvm and lld checkouts are not quite in synch. It will be worth updating llvm and lld to top of trunk. I've rebased the consolidated patch https://reviews.llvm.org/D34634 this morning, it might be worth trying that if you are seeing problems. Peter On 29 June 2017 at 22:09, Alessandro Pistocchi <apukfreelance at gmail.com> wrote: > Hi, I tried

The next feature on my DWARF 5 list is the line-table header. While this is pretty easy generate, it is a real bear to parse, so I thought I should let y'all know what I'm up to and why as I head out to the yak farm. Any thoughts and suggestions would be very much appreciated. The v5 directory and file tables no longer have a fixed format; instead, we have a list of field descriptors

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

On Thu, Sep 15, 2011 at 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: >

Hey Evan, At the point of the instructions you suggested I step through, X86ISelLowering has this state: - this 0x00000000005fe728 {VarArgsFrameIndex=-842150451 RegSaveFrameIndex=-842150451 VarArgsGPOffset=3452816845 ...} llvm::X86TargetLowering * const + llvm::TargetLowering {TM={...} TD=0x00000000008edac0

The bottom of the bug has the revision numbers (e.g. D34035). That one corresponds to e.g. https://reviews.llvm.org/D34035 There's also https://reviews.llvm.org/D34634 which contains all of Peter's patches, but it's not going to rebase cleanly once the individual patches start going in. On 6/28/17, 10:56 AM, "Alessandro Pistocchi" <apukfreelance at gmail.com> wrote:

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

On Sat, May 5, 2012 at 10:01 PM, Benjamin Kramer <benny.kra at googlemail.com>wrote: > > On 05.05.2012, at 17:52, Dmitry Vyukov wrote: > > > 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 {

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

Proposal for ELF text and data big endian support for direct object generation Unless I am mistaken, currently big endian support in the MC layer for ELF direct object generation is limited to ELF headers and tables like relocations. Text and data section contents are still generated as individual bytes. It looks as if the effort was started, but never completed. The proposal is to extend the

On 05.05.2012, at 17:52, Dmitry Vyukov wrote: > 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 { > ... >

On 06.05.2012, at 08:01, Dmitry Vyukov wrote: > On Sat, May 5, 2012 at 10:01 PM, Benjamin Kramer <benny.kra at googlemail.com> wrote: > > On 05.05.2012, at 17:52, Dmitry Vyukov wrote: > > > Hi, > > > > I would like to extend DebugInfo library for the purpose of using it in AddressSanitizer/ThreadSanitizer run-time libraries. > > > > Current

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