search for: objectfiles

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

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

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:

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

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:

Could someone apply the attached patch for the ObjectFiles.html document? Thanks, Reid. -------------- next part -------------- A non-text attachment was scrubbed... Name: ObjectFiles.html.patch Type: text/x-patch Size: 4952 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040227/3f6f07e4/attachment.bin> ------...

...es are fine-grained _enough_. They probably are so I'm not going to make an issue out of this because there are bigger fish to fry. > Well, in the long term we want to switch everything over to docbook, at > which point it should just be a matter of doing the equiv of "#include > ObjectFiles.html", and we suddenly have a new section in the book... DocBook is good. I'd rather use that than HTML. There's got to be an HTML to DocBook translator around *somewhere*. Is there a Bugzilla for this work? Need me to work on this or has it already started? Reid. -------------- next...

...ly be integrated into > > the programmers manual though? > > Perhaps, but with hypertext, what does "integrated" really mean? :) Well, in the long term we want to switch everything over to docbook, at which point it should just be a matter of doing the equiv of "#include ObjectFiles.html", and we suddenly have a new section in the book... -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/

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

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

...to make an issue out of this because there > are bigger fish to fry. If not, they can always be split up later. :) > > Well, in the long term we want to switch everything over to docbook, at > > which point it should just be a matter of doing the equiv of "#include > > ObjectFiles.html", and we suddenly have a new section in the book... > > DocBook is good. I'd rather use that than HTML. There's got to be an > HTML to DocBook translator around *somewhere*. Is there a Bugzilla for > this work? Need me to work on this or has it already started? The fi...

Hi Christian Your use case seems to have similar requirements as remote JITing in ORC. So far I haven't used that part myself and I am sure Lang can tell you much more about it. However, this comment on the RemoteObjectClientLayer class sounds promising for your questions (1) and (2): /// Sending relocatable objects to the server (rather than fully relocated /// bits) allows JIT'd code

Hi everyone, Having proper error handling in LLVM's Object parsing library is a nice thing by itself, but it would additionally allow us to find bugs by fuzzing (see r238451 that adds llvm-dwarfdump-fuzzer tool), for which the clean input validation is essential. This is a generic discussion of state of affairs. I want to do some progress in fuzzing before we finish it (especially if we

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 Thu, 2004-02-26 at 22:41, Chris Lattner wrote: > On Fri, 27 Feb 2004, Chris Lattner wrote: > > > Could someone please add this file to the LLVM docs directory so I can > > > submit patches against it? > > BTW, here's some hints for it: Thanks Chris, I'll add them. > Basically, libraries are built in two forms: .a files and .o files. .o > files are

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

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

...rary archives. It would be very useful if there was a map of the dependencies between the files (e.g. if you link X.o you need Y.a and Z.o). Trying to figure out the link lines by trial and error is a bit frustrating. To assist myself with understanding this, I've started to write a document (ObjectFiles.html, attached) that will (eventually) explain all this. Right now its pretty much just a list of the various files produced by building LLVM and a cursory statement of what the file contains. The most significant need in the document is for a section on the dependencies between the various files...

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 =