search for: libobject

...entation of Objective-C metadata reader library to LLVM. Unlike the C style objective-c metadata reader in llvm-objdump, it is designed to be a reusable C++ library to parse objective-c metadata from binaries with LLVM style error handling. The current implementation has an interface that resembles libObject in and it supports parsing objective-c metadata from MachO object file or LLVM bitcode that is generated by clang/swift compiler. It has the flexibility to be extended to support other objective-c metadata format if needed. You can find an old open-source version of implementation here[1]. The vers...

...; return, but I assume it's rare to parse a single relocation in isolation. > Why don't we validate all relocations for each section up front, then have > a simpler API for accessing them? > > I don't have especially strong feelings about this, just a nagging sense > that libObject's error handling is unnecessarily fine grained. > > FWIW, of the other two proposals I prefer the ErrorOr approach. > > Cheers, > Lang. > > On Fri, May 29, 2015 at 6:45 PM, Sean Silva <chisophugis at gmail.com> wrote: > >> >> >> On Fri, May 29, 20...

...e solution is to have a style guideline: You can't use reference types (in the general sense - references, pointers, etc.) in errors. Errors that would otherwise require references should have their error-message stringified at the point of creation. > > Consider someone who wants to use libObject to write an object-file repair > > tool: A "bad_symbol" error code tells you what went wrong, but not where or > > why, so it's not much use in attempting a fix. On the other hand "bad_symbol > > { idx = 10 }" gives you enough information to pop up a dialog...

...er + load commands) fits into the binary so the offsets don't need to be recalculated, otherwise suggests to relink the binary with -headerpad / -headerpad_max_install_names / reports an error). One possible (and simple) approach is to implement llvm-install-name-tool in a similar fashion: use libObject to parse the input binary and rebuild the list of load commands (analogously to what cctools' install_name_tool does (and with the same limitations)). I'd like to ask for your general feedback / thoughts / suggestions on contributing llvm-install-name-tool to LLVM with the goal to be a drop...

...for standard Unix .a files by slightly extending a code in llvm-nm, and the code crashed with wild segfault. It looks like the implementation in lib/Object/Archive.cpp assumes completely different symbol table format from what I have (which I believe is SVR4/GNU variant). Which archive formats does libObject support, and are there any plans to extend it? -- Alexey Samsonov, MSK -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120803/059a6a5d/attachment.html>

...t either of them require much. > Note that with error_code one can define arbitrary error categories. The problem with error categories is that they're limited to static groupings of kinds of errors, but the user might need dynamic information to recover. Consider someone who wants to use libObject to write an object-file repair tool: A "bad_symbol" error code tells you what went wrong, but not where or why, so it's not much use in attempting a fix. On the other hand "bad_symbol { idx = 10 }" gives you enough information to pop up a dialog, ask the user what the symbol...

...ly need to install them in > many different locations without simply relinking the files? > > Turning to practical matters, is your intent to have the load-command > rewriting code live in the tool? Or are you proposing adding support for > building/swapping/rewriting Object files to libObject? > > MDT > > > On Oct 11, 2019, at 10:31 AM, Alexander Shaposhnikov < > alexander.v.shaposhnikov at gmail.com> wrote: > > Hey everyone! > Recently there has been some progress on LLVM-based tools for manipulating > MachO binaries: llvm-objcopy has been gaining a...

...and writing records in binary file formats, this is not a new issue. The proposal: This code has been used in LLVM's PDB library for some time, and I want to move it up to Support. I've discussed this with some people offline. beanz@ has expressed interest for some work he wants to do on libobject. It can also replace a few thousand lines of (untested) code in LLDB that does essentially the same thing. I suspect it can be used anytime anyone is reading from or writing to a binary file format, perhaps even being faster than existing implementations due to the zero-copy aspect. I have a (so...

...;re certain the result would be > valid. > > On IRC discussion Lang suggested > 3. Check the whole object file contents in constructor or validate() > method, and get rid > of all error codes in regular accessors. > Unfortunately this option isn't possible with the current libObject. libObject is specifically designed to avoid paging in or allocating any memory beyond simply mmap'ing the file. This makes it annoying to use, but also allows it to be used for demanding use cases like a linker. For many things, I've always wished we had a "libEasyObject" that av...

...ission support. > thanks for your response, did MC layer's direct object emission depends on > Object library? > > Nope. The Object library only reads object files. MC, on the other hand, > only writes object files. > That’s true for object emission, but MC already depends on libObject, and at least some of the more experimental parts of MC actually use it to read files. However, - I believe nobody mentioned this - I think the point of having ELF.h and friends in Support is that they’re intended to (more or less exactly) match the headers provided by the system. Most of what’s t...

...lone tool instead of as a frontend for llvm-ar. (llvm-ranlib is an example of a frontend for llvm-ar, where it's the same underlying binary which just does different option parsing depending on how it's invoked.) Much of the archive writing logic that llvm-ar uses is already factored out to libObject (the writeArchive function), and we can factor more of it out as needed, so we shouldn't end up with too much duplicated code between llvm-ar and llvm-libtool. At the same time, making llvm-libtool its own tool gives us the freedom to e.g. factor out parts of llvm-lipo into a library to handle...

On Jul 4, 2013, at 10:22 PM, 罗勇刚(Yonggang Luo) wrote: > > 在 2013-7-4 下午8:53，"Charles Davis" <cdavis5x at gmail.com>写道： > > > > > > On Jul 4, 2013, at 1:43 AM, 罗勇刚(Yonggang Luo) wrote: > > > > > LLVM is a modularized software system, so I hope it's was modularized, > > > And ELF.h is definitely belongs to Object by

...>> Also seems like this could/should/needs to be sunk into BinaryFormat? >> > > These things are really more PE/PDB related than CodeView. They are in the > wrong place. I'd ask Saleem to help find a new home. Object or > BinaryFormats seem OK to me. > Moved it to libObject (r328593) for now which is at least correct - if someone thinks it'd be more suited to BinaryFormat, I'm happy to move it or they can. > > >> I'm open to ideas & happy to do the work, or help in any way that might >> be useful. >> >> Thanks, >>...

...files by slightly extending a code in llvm-nm, > and the code crashed with wild segfault. It looks like the implementation in > lib/Object/Archive.cpp assumes completely different symbol table format from > what I have > (which I believe is SVR4/GNU variant). Which archive formats does libObject > support, and are there any plans to extend it? > > -- > Alexey Samsonov, MSK > I believe it currently only supports the llvm and Microsoft symbol table format. I really should have documented that while writing the code ;/ My intent was to extend it to support both gnu and bsd st...

...to BinaryFormat? >>>> >>> >>> These things are really more PE/PDB related than CodeView. They are in >>> the wrong place. I'd ask Saleem to help find a new home. Object or >>> BinaryFormats seem OK to me. >>> >> >> Moved it to libObject (r328593) for now which is at least correct - if >> someone thinks it'd be more suited to BinaryFormat, I'm happy to move it or >> they can. >> >> >>> >>> >>>> I'm open to ideas & happy to do the work, or help in any way that mig...

...blem on OSX (it doesn't use them) and wasn't a > problem on linux at the time I wrote it, but clang now emits DWARF that > makes use of relocations so they have to be resolved before the buffers are > passed to the DWARFContext. We should have the necessary stuff in LLVM's > libObject, so it shouldn't be too hard. > > I see. Perhaps it's already fixed in lldb, lldb should work with llvm-generated binaries. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120506/dd45f90f/attach...

Hi all, I'm trying to support llvm-cov for a new architecture and I have successfully built compiler-rt for my arch. Following steps shown in https://clang.llvm.org/docs/SourceBasedCodeCoverage.html , I encountered an error for the last step(step of llvm-cov show). The command line was (supposed my arch is XXXX) "llvm-cov show -arch=XXXX ./foo -instr-profile=foo.profdata" and the

...coverage: No object file for requested architecture." > > > > I think I should add my arch information to somewhere(maybe an llvm-cov > support list?) but I don't know where to add these information. Can > someone give me some suggestions? > > You’ll need to teach libObject about this architecture. Specifically, the > coverage reader checks that calling getArch() on a loaded ObjectFile matches > Triple(Arch).getArch() (see loadBinaryFormat in > CoverageMappingReader.cpp). > > best, > vedant > > > > > > Best Regards, > > Ruo...

...t;commit after approval" rights to the repo by Chris Lattner, and will start delivering patches to llvm-commits today. To make the review process manageable, we intend to split the patches into a few incremental parts: 1. Modifications (more precisely, extension) to ELFObjectFile (from libObject) to support dynamic loading 2. Implementation of MC-JIT for ELF, including a new RuntimeDyldELF class (that parallels the existing RuntimeDyldMachO) which implements the dynamic loading of the ELF image into memory, its relocation and execution. 3. An implementation of a MC-JIT - GDB...

...ck of good error reporting in Orc and MCJIT has forced me to spend a lot of time investigating hard-to-debug errors that could easily have been identified if we provided richer error information to the client, rather than just aborting. Kevin Enderby has made similar observations about the state of libObject and the difficulty of producing good error messages for damaged object files. I expect to encounter more issues like this as I continue work on the MachO side of LLD. I see tackling the error modeling problem as a first step towards improving error handling in general: if we make it easy to model e...