similar to: [LLVMdev] Fwd: Minor typo in source file ObjectFile.h (CANCELLATION)

const uint64_t UnknownAddressOrSize <http://llvm.org/doxygen/namespacellvm_1_1object.html#abcfa9b6f24c69c52d2489a102ba3583c> = ~0ULL This found at line 260 in ObjectFile.h. Notice the 0ULL thingy. Cheers, Mikael -- Love Thy Frog! -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

While working on some other changes I came across a problem where ELFObjectFile::getSymbolFileOffset was returning a different value than I expected in the case where the symbol in question was a section. Looking at the code, it seems obviously wrong, but I didn't want to just commit my change without at least asking if anyone knew of a good reason for the current behavior. I know there

Hey! I've been studying the LLVM C bindings (include/llvm-c/) and it 's not very clear to me how I could create an ELF object file with them. Function "LLVMCreateObjectFile" (in Object.h) needs an "LLVMMemoryBufferRef" object but I'm not sure how I should create one using the created "LLVMModuleRef". The reason why I want to use the C bindings and

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

On Mon, December 19, 2016 12:41 am, Sorin Srbu wrote: >> -----Original Message----- >> From: CentOS [mailto:centos-bounces at centos.org] On Behalf Of >> geo.inbox.ignored >> Sent: den 16 december 2016 15:03 >> To: centos at centos.org >> Subject: Re: [CentOS] OT: Blank mails from this list >> >> >> >> On 12/16/2016 07:29 AM, Valeri

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

First of all, apologies for our hilarious system architecture. It's this way for historical reasons. I had a setup that worked; I now have a setup that doesn't work and I'm trying to work out why. The setup that worked: OS X Tiger (10.4) Server as PDC. Linux servers (a variety of flavours, from Ubuntu 8.04 LTS to SLES 11 SP2) getting user information from the server by LDAP and

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

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

I have a few questions about the new ORC JIT. I saw Lang Hames (hi!) excellent talk at the llvm-dev meeting a few weeks ago. The ORC JIT is undergoing some API changes and I'd like/need to take advantage of them. (1) How do I take ownership of the ObjectFile once the ORC JIT has created it? I'd like to take ownership of object files generated by the ORC JIT so that I can save them to

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

Hi Dave Sorry, I meant the hardware you're using to compile LLVM - you mentioned it took you a long time to rebuild it so it would be hard for you to write/experiment on tests. ============================= Compiling LLVM doesn't take me too much time(less than 2 hours). The hardware is good enough and I am using interl E5 CPU. What I mean is that it took me a long time to analysis the

On 25 Sep 2013, at 22:22, Renato Golin <renato.golin at linaro.org> wrote: > Documentations get outdated more often than comments in the code, and LLVM is particularly good at generic comments, but not so much at teaching how to use the code. > > Patches adding comments are also a good way to learn how something works. You send a comment, people say how wrong that is, and in the

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