search for: symbolref

Hi everyone, I’m currently playing with the clang driver and I encounter a strange bug. It occurs when I used the getSize function from the SymbolRef class. On iOS, the number returned is not always correct (some function have the right size). Sadly, This is my code (at the end of the main function into driver.cpp) : #### ErrorOr<OwningBinary<Binary>> BinaryOrErr = createBinary(file); if (std::error_code ec = BinaryOrErr.getErro...

I'm working on adding data detection to llvm-objdump, so it prints out raw data for symbols with type SymbolRef::ST_Data instead of disassembling them. This causes llvm/test/MC/ARM/Windows/mov32t-range.s to fail, because the symbol "truncation" comes back as SymbolRef::ST_Data, and the code gets dumped as bytes instead of disassembled. I traced the problem back to COFFObjectFile::getSymbolType(...

...in question? It may make more sense to try to key off of those section characteristics as well. On Fri, Aug 22, 2014 at 9:55 AM, Ted Woodward <ted.woodward at codeaurora.org> wrote: I’m working on adding data detection to llvm-objdump, so it prints out raw data for symbols with type SymbolRef::ST_Data instead of disassembling them. This causes llvm/test/MC/ARM/Windows/mov32t-range.s to fail, because the symbol “truncation” comes back as SymbolRef::ST_Data, and the code gets dumped as bytes instead of disassembled. I traced the problem back to COFFObjectFile::getSymbolType() in llvm/...

...d to use "CompileLayer.findSymbolIn(H, Name, false)" in "KaleidoscopeJIT::findMangledSymbol" to also allow non-exported symbols. I fixed it by changing "COFFObjectFile::getSymbolFlags" in llvm-src/lib/Object/COFFObjectFile.cpp to additionally OR SymbolRef::SF_Exported to Result: > uint32_t COFFObjectFile::getSymbolFlags(DataRefImpl Ref) const { > COFFSymbolRef Symb = getCOFFSymbol(Ref); > uint32_t Result = SymbolRef::SF_None; > > if (Symb.isExternal() || Symb.isWeakExternal()) > Result |= SymbolRef::SF_Global | SymbolRef...

Hi all, I'm using the MC framework for a project, and while updating to latest trunk (r148672) encountered the following issue: It seems that SymbolRef::getAddress and SymbolRef::getFileOffset have been changed to add the symbol's offset to the offset of the containing section? This has the following implications: To get the /actual/ fileoffset, I now need to do: Symbol.getFileOffset() - ContainingSection.getFileOffset() And to get the addre...

I have a case where I the expression (MCSymbolRefExpr) is the offset from the beginning of the section. The need is to combine that offset to the virtual address of the section it belongs, in this case .text, but it could be any section. I can get a MCSectionELF class object from MCSymbol that I get from MCSymbolRefExpr: int Kind = Value->...

...statement. Applies cleanly > to r148473 now. Are there more comments on the code? Thank you!! + assert(Inst.getOperand(0).isReg() && + (Inst.getOperand(ImmOp).isImm() || + (Inst.getOperand(ImmOp).isExpr() && + Inst.getOperand(ImmOp).getExpr()->getKind() == MCExpr::SymbolRef) && + static_cast<const MCSymbolRefExpr*>(Inst.getOperand(ImmOp).getExpr())->getKind() == MCSymbolRefExpr::VK_SECREL) && Just asserting "Inst.getOperand(ImmOp).isImm() || (Inst.getOperand(ImmOp).isExpr()" should be sufficient here; in theory, a wide variety of...

Hello LLVM, I'm trying to make symbolizing work in llvm-objdump. This comment in ObjectFile.h gives me some heartburn: https://github.com/llvm-mirror/llvm/blob/master/include/llvm/Object/ObjectFile.h#L196 // The main goal of // this is to allow SymbolRef::SymbolPimpl to point directly to the symbol // entry in the memory mapped object file. SymbolPimpl cannot contain any // virtual functions because then it could not point into the memory mapped // file. Is this still a goal and if so, why? Building symbol objects on top of the file's memory...

Hi! I added 2 more tests and also refined an assert statement. Applies cleanly to r148473 now. Are there more comments on the code? Thank you!! Regards Kai On 01.01.2012 22:01, Eli Friedman wrote: > On Sun, Jan 1, 2012 at 10:44 AM, Kai<kai at redstar.de> wrote: >> Happy new year to all! >> >> The attached patch adds TLS support for x86_64-pc-win32 and x86-pc-win32.

...the same. What would be the recommended >> approach to achieving this goal? > > I have a similar use case and would also be interested in an answer. In the meantime, I have a horrible hack that may work for you. > > My current hack works because the returned StringRefs for the SymbolRef::getContents are within the range of the MemoryBuffer and so the offset relative to the memory buffer corresponds to the file offset and this offset can be used to write into the file directly. > > It’s a horrible hack though, and it would be nice to simply have a mutable memory buffer that...

...+ const ObjectFile &DebugObj = *DebugObjOwner.getBinary(); > + > + // Get the address of the object image for use as a unique identifier > + DWARFContextInMemory Context(DebugObj); > + > + // Use symbol info to iterate functions in the object. > + for (const std::pair<SymbolRef, uint64_t> &P : computeSymbolSizes(DebugObj)) { > + SymbolRef Sym = P.first; > + std::vector<LLVMPerfJitDebugEntry> LineInfo; > + std::string SourceFileName; > + > + Expected<SymbolRef::Type> SymTypeOrErr = Sym.getType(); > + if (!SymTypeOrErr) {...

Hi, I've been trying to write a tool that reads in an ELF file and modifies one section within that ELF file based on the data contained within another section. Using llvm-objdump as a template of how to read an object file, I've been able to read the latter section that tells me what to edit, but I haven't found a way to edit the former, as everything in the

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

...dev at cs.uiuc.edu > Subject: [LLVMdev] ELFObjectFile changes, llvm-objdump showing 'wrong' > values? > > Hi all, > > I'm using the MC framework for a project, and while updating to latest trunk > (r148672) encountered the following issue: > > It seems that SymbolRef::getAddress and SymbolRef::getFileOffset have > been changed to add the symbol's offset to the offset of the containing > section? > > This has the following implications: > > To get the /actual/ fileoffset, I now need to do: > Symbol.getFileOffset() - ContainingSection.g...

...gsi->second.first; + Value.Offset = gsi->second.second; Value.Addend = gsi->second.second + Addend; } else { switch (SymType) { @@ -860,6 +890,7 @@ void RuntimeDyldELF::processRelocationRe Value.Addend = Addend; break; } + case SymbolRef::ST_Data: case SymbolRef::ST_Unknown: { Value.SymbolName = TargetName.data(); Value.Addend = Addend; @@ -1150,8 +1181,67 @@ void RuntimeDyldELF::processRelocationRe ELF::R_390_PC32DBL, Addend); else resolveRelocation(Section, Offse...

Hi Ulrich, and any other llvm PowerPC/JIT users, It looks like the Numba maintainers have run in to an issue with RuntimeDyldELF's PowerPC support (See https://github.com/numba/numba/issues/2451#issuecomment-377739948 and later comments) Due to a recent change to weak symbol handling, we now always resolve to the first copy of a function that is emitted (discarding redundant weak/odr

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

...a simple pointer increment. And most object files will support random access to the symbol and section table. The API needs lots of work. Some of the current problems include: * Error handling. * Symbols only. * Can only access one symbol table efficiently. * Read only. * Weird interface between SymbolRef and ObjectFile. My current plan to support modifying and creating new object files is to have a generic internal representation that has the same external API as everything else. When the API client calls any function that modifies the object file, a "changes" object is created that stor...