search for: objectfile

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: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120531/d952ed02/attachment.html>

> 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. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE P...

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 unique_ptr. The flow from when it was created to getElfArchType is pretty direct. The segfault only happens only at optimization level -O0. The segfau...

...m-7/llvm/lib/DebugInfo/DWARF/DWARFContext.cpp:351:0 #23 0x0000000000448e28 llvm::DWARFContext::dump(llvm::raw_ostream&, llvm::DIDumpOptions, std::array<llvm::Optional<unsigned long>, 27ul>) /home/linux/llvm-7/llvm/lib/DebugInfo/DWARF/DWARFContext.cpp:355:0 #24 0x0000000000414af6 dumpObjectFile(llvm::object::ObjectFile&, llvm::DWARFContext&, llvm::Twine, llvm::raw_ostream&) /home/linux/llvm-7/llvm/tools/llvm-dwarfdump/llvm-dwarfdump.cpp:424:0 #25 0x0000000000425d9a std::_Function_handler<bool (llvm::object::ObjectFile&, llvm::DWARFContext&, llvm::Twine, llvm::raw_os...

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, "seg...

...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: LLVMdev Mailing List <llvmdev at cs.uiuc.edu> 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...

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

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

...ntext.cpp:351:0 >> #23 0x0000000000448e28 llvm::DWARFContext::dump(llvm::raw_ostream&, >> llvm::DIDumpOptions, std::array<llvm::Optional<unsigned long>, 27ul>) >> /home/linux/llvm-7/llvm/lib/DebugInfo/DWARF/DWARFContext.cpp:355:0 >> #24 0x0000000000414af6 dumpObjectFile(llvm::object::ObjectFile&, >> llvm::DWARFContext&, llvm::Twine, llvm::raw_ostream&) >> /home/linux/llvm-7/llvm/tools/llvm-dwarfdump/llvm-dwarfdump.cpp:424:0 >> #25 0x0000000000425d9a std::_Function_handler<bool >> (llvm::object::ObjectFile&, llvm::DWARFCon...

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 disk and in later sessions reload them. (2) How would I pass an ObjectFile saved in question#1 back to ORC so that it will relocate it and generate function pointe...

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

...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 disk and in later sessions > reload them. > (2) How would I pass an ObjectFile saved in question#1 back to ORC > so...

...s. I want to do some progress in fuzzing before we finish it (especially if we decide to make a significant intrusive changes), you may scroll down for my plan. The code in lib/Object calls report_fatal_error() far too often, both when we're (a) just constructing the specific implementation of ObjectFile, and (b) when we access its contents and find out the file is broken and can't be parsed properly. We should just go and fix (a): ObjectFile factory methods return ErrorOr<std::unique_ptr<ObjectFile>>, and we should propagate the error appropriately. (b) is harder. The current app...

...lt;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 Object was getting corrupted.  The only thing that distinguished > this pointer was that it was declared as a unique_ptr.  The flow from when > it was created to getElfArchType is pretty direct. > > The segfault only happens only at optimization...

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

...#23 0x0000000000448e28 llvm::DWARFContext::dump(llvm::raw_ostream&, >>>> llvm::DIDumpOptions, std::array<llvm::Optional<unsigned long>, 27ul>) >>>> /home/linux/llvm-7/llvm/lib/DebugInfo/DWARF/DWARFContext.cpp:355:0 >>>> #24 0x0000000000414af6 dumpObjectFile(llvm::object::ObjectFile&, >>>> llvm::DWARFContext&, llvm::Twine, llvm::raw_ostream&) >>>> /home/linux/llvm-7/llvm/tools/llvm-dwarfdump/llvm-dwarfdump.cpp:424:0 >>>> #25 0x0000000000425d9a std::_Function_handler<bool >>>> (llvm::object:...

...is how they are numbered in COFF. -2, -1, and 0 > are special section indices. > > > BTW - patch attached to add pre-increment to llvm::content_iterator > (which is the template base for section_iterator, etc) > > > > -- Marshall > > > Index: include/llvm/Object/ObjectFile.h > =================================================================== > --- include/llvm/Object/ObjectFile.h (revision 158307) > +++ include/llvm/Object/ObjectFile.h (working copy) > + content_iterator& operator++() { > + error_code ec; > + return this-&gt...

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

...e). 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.getError()) { return ec.value(); } Binary &Binary = *BinaryOrErr.get().getBinary(); object::ObjectFile *objfile; objfile = dyn_cast<ObjectFile>(&Binary); for (const SymbolRef &Symbol : objfile->symbols()) { uint64_t size; Symbol.getAddress(size); } #### During my previous search, I check machODump.cpp in order to see of the list all the function. They never use the getSize()...