similar to: [LLVMdev] awkward object file abstractions

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 =

Hi, On 2017-02-01 23:20:40 -0800, Andres Freund wrote: > > 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 and in. If it's more complicated, I probably won't have the > > time to assist. > > Patch (and a prerequisite) attached. Took me a while to get

Actually, MCJIT doesn't perform relocations on debug sections. I'm not sure that would matter anyway. The place where I'm handling the debug information is outside MCJIT and the MCJIT relocation code isn't really accessible at that point. Right now, when MCJIT emits an object image, it broadcasts an event to any registered listeners indicating that an object was emitted, passing

I found how to build CRC32 table for Ogg in JS, if anyone interested: function _makeCRC32Table() { // From https://stackoverflow.com/questions/53438815/hot-to-build-crc32-table-for-ogg const polynomial = 79764919; const mask = 2147483648; const CRCTable = new Uint32Array(256); for (let i = 256; i--;) { let char = i << 24; for (let j = 8; j--;) {

A few days ago we were discussing object files and linking on IRC. I had been thinking about working on this for a while, and this discussion finally got me to do it. Attached are patches of a preliminary implementation of a generic object file library, and a few changes to llvm-nm to make use of it. The main goal in the design of the API is to allow a fast implementation by avoiding memory

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

The section is .text, so I assume it’s got IMAGE_SCM_CNT_CODE set. The problem is the symbol is marked (read & execute), but the test is (read & !write), so the symbol gets marked as ST_Data instead of ST_Other. From: David Majnemer [mailto:david.majnemer at gmail.com] Sent: Friday, August 22, 2014 5:44 PM To: Ted Woodward Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev]

Hello, The ObjectFile class (in Object/ObjectFile.h) presents a format-independent interface for object files. In addition, for COFF and MachO, some internal format details are exposed in special headers. For example, Object/COFF.h exposes coff_file_header and coff_symbol. Object/MachOFormat.h exposes headers, "segment load commands" and so on. ELF, however, is not exposed and

Hi, I'm currently working my way through the tutorial with LLVM 3.9.1 on Windows (finished chapter 4) and stumbled over a few things which could be improved: - "LLVMContext" does not exist as a variable -> "TheContext" - Chapter 3: 5 times - Chapter 4: 1 time - Chapter 5: 4 times - Chapter 6: 2 times - Chapter 7: 2 times 3.4. Function Code

I've been debugging a segfault issue with the elfreader and I would like to point out something that I have noticed. ELF.h declares an inline function, getElfArchType (MemoryBuffer *Object). When this function is called from ObjectFile::createELFObjectFile the pointer to Object was getting corrupted. The only thing that distinguished this pointer was that it was declared as a

On Sat, Jun 30, 2012 at 7:58 AM, Sid Manning <sidneym at codeaurora.org> wrote: > > I've been debugging a segfault issue with the elfreader and I would like to > point out something that I have noticed. > > ELF.h declares an inline function, getElfArchType (MemoryBuffer *Object). >  When this function is called from ObjectFile::createELFObjectFile the > pointer to

On Fri, 3 Dec 2004, Reid Spencer wrote: > Could someone please apply this patch to the Win32 support so that > Morten and Jeff can handle the recent changes? I can't do it because > I"m on the road with only email access. I'd be happy to do it. Can someone send me the patch as an attachment off-list? -Chris > > <Tool > >

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

Hi I come across the following exception when I use the llvm-dwarfdump -debug-info target_binary: llvm-dwarfdump: /home/linux/llvm-7/llvm/lib/MC/MCRegisterInfo.cpp:87: int llvm::MCRegisterInfo::getLLVMRegNum(unsigned int, bool) const: Assertion `I != M+Size && I->FromReg == RegNum && "Invalid RegNum"' failed. Stack dump: 0. Program arguments:

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Mikael Lyngvig > Subject: [LLVMdev] Minor typo in source file ObjectFile.h > const uint64_t UnknownAddressOrSize = ~0ULL > This found at line 260 in ObjectFile.h.  Notice the 0ULL thingy. What do you find troubling about it? It's simply a way to set all bits in an unsigned variable. -

Michael, would it be possible for you to plant a strategically placed block comment explaining the situation with the "pointless" error_code stuff, like you explained to me? I'm not sure where is best, but it is worth having written down somewhere. --Sean Silva On Tue, Jun 12, 2012 at 1:08 PM, Michael Spencer <bigcheesegs at gmail.com>wrote: > On Mon, Jun 11, 2012 at 5:41

Hi Dave I am not going to access any hardware. I am using clang to analysis the ARM binaries. The binary is 483.xalancbmk in CPU SPEC2006. When I use the optimization O0, no crash will occur. The crash occurs when I set optimization level as O1,O2,O3 and Os. If I have to recompile and rerun the tests. What version of llvm is suggested. It would be better if anyone could provide the patch on this

Please see the documentation: https://xiph.org/ogg/doc/framing.html I would encourage you to use random serial numbers, as intended, also, as any downstream consumers of your files will face limitations similar to the ones you are facing if they want to do anything more with them. But before you go too far down the route of changing the serial numbers, can you tell us what software is

Here we go again... It took me a while to figure out that the stuff below is valid: ~0ull. I never saw the suffix written in uppercase before and the code below must be eligble for a price in hilarious coincidences. Cheers, Mikael ---------- Forwarded message ---------- From: Mikael Lyngvig <mikael at lyngvig.org> Date: 2012/5/31 Subject: Minor typo in source file ObjectFile.h To:

On Mon, Jun 11, 2012 at 5:41 PM, Marshall Clow <mclow.lists at gmail.com> wrote: > So, I'm trying to use this file to look inside COFF files. > Got the header. OK. > > Now I want to look at the sections. > Look, there's a section iterator. I can use that! > > So, I write: >        for (llvm::object::section_iterator iter = Obj.begin_sections (); iter !=