similar to: contributing llvm-install-name-tool

Hey Michael, I completely agree that setting the rpath properly the first time around is much preferred. But, changes to the binary, particularly during development is much quicker. Prebuilt libraries which are being repackaged is one use case that is missed. In the past, I’ve even used it to repair am incorrectly built library which was missing the library name. There are a few different

Hey everyone! Objcopy is a powerful tool that allows one to modify object files in various manners, for example, modify symbols / symbol tables or copy / remove particular parts of a binary. It also serves as a basis for the strip tool. Currently, llvm-objcopy only supports ELF files while binutils' objcopy can handle Mach-O files as well. Besides extending the existing tool to support Mach-O

That's something I want to do as well for several reasons. That's an orthogonal issue however. On Tue, Oct 2, 2018, 10:21 AM Eric Christopher <echristo at gmail.com> wrote: > I'd give some consideration to moving the objcopy support itself into a > library inside llvm (possibly lib/Object as that makes the most sense) and > then the tool is just a thin wrapper on top

Hi Jake, many thanks, yea, I have very similar feelings / thoughts. After some thinking it seems to me that this discussion/problem which I have brought up is, in fact, more relevant to the tools which really need a robust mutable model of an object file (like objcopy, strip, install_name_tool, etc), but the particular case of "lipo" might be simpler, I need to double check that / will

Every case is different, but yes, as I said - I would like to take a closer look at the problem again, it might be the case that we don't need this complexity in this particular case, but want to double check. But yeah, in general I agree with you! On Thu, May 9, 2019 at 6:09 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > I think that pretty much hits the nail on the head.

Hey everyone! In October/November 2018 I started the implementation of llvm-objcopy for MachO with the long-term plan to build some popular binary-level tools on top of it. That effort stopped at the stage where some boilerplate code for reading/writing MachO files was reviewed & committed to LLVM/tools/llvm-objcopy. Later I started working on llvm-lipo (a drop-in replacing for the tool

*bitcode_strip* is a utility which is used to manipulate (leave / remove) bitcode segments in a Mach-O file. It is a part of Apple’s cctools and it is also distributed with Xcode. The man page of the tool is available here https://www.manpagez.com/man/1/bitcode_strip/. The functionality of *bitcode_strip* naturally maps onto llvm-objcopy’s model and requires only minimal additions to it.

We're planning to contribute an LLVM version of Apple's libtool utility. To quote its man page, "Libtool with -static is intended to replace ar(5) and ranlib". In other words, libtool is the preferred tool to create archives for Apple platforms, and it also has good defaults for that platform (e.g. automatically creating a table of contents with the right format). It provides a

I believe it's a feature missing in MC - https://github.com/opensource-apple/cctools/blob/4da58fd2fc026317ed9e9ef1feabf21ed0bb7a81/cctools-836/as/i386.c line 539 adds support for the .bss directive if certain variables are defined, and mainline gas supports it on all ARM targets: https://sourceware.org/binutils/docs/as/ARM-Directives.html . Supporting the directive on all Darwin targets could

> So the situation for LLD being used as a library is analogous to LLVM IR libraries being used from clang. In general, clang knows that it just generated the IR and that the IR is correct (otherwise it would be a bug in clang), and thus it disables the verifier. That sounds good, but we can only usually trust our inputs. There are still some awfully crusty object files out in the world, so we

Thanks for your response, that's kinda what I've gathered over the years. I was hoping that the Xcode project would have "just worked". I'll keep piece-mealing it together, and hope that it works. I'll try to post a radar. Joe Joe Abbey Director of S/W Development Arxan Technologies, Inc. 1305 Cumberland Ave, Ste 215 West Lafayette, IN 47906 W: 765-889-4756 x2 C:

LGTM On 29 September 2013 06:08, Nicholas White <n.j.white at gmail.com> wrote: > I believe it's a feature missing in MC - > https://github.com/opensource-apple/cctools/blob/4da58fd2fc026317ed9e9ef1feabf21ed0bb7a81/cctools-836/as/i386.c > line 539 adds support for the .bss directive if certain variables are > defined, and mainline gas supports it on all ARM targets: >

On 14.01.2012, at 17:23, Joe Abbey wrote: > I have a need to build ld from source to understand an assert(0). > > I got excited when I found that ld64 on the opensource portal contains an xcodeproj > > http://opensource.apple.com/source/ld64/ld64-127.2/ > > But... it seems like I'm lacking mach-o/arm/reloc.h, and dyld_priv.h. > > I'm doing my best to stitch

Overview ======= We are planning to open source our internal implementation 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

Hello all, I tried to build R-2.3.1 from source under Mac OS X 10.4.6. (I am doing so because only this way I can get the 64-bit version of R) The configure and make steps look fine. But I got errors when I did make check-all, here is the message: running code in 'base-Ex.R' ...make[4]: *** [base-Ex.Rout] Error 1 make[3]: *** [test-Examples-Base] Error 2 make[2]: *** [test-Examples]

Was there any progress in the upstreaming effort? I'd be interested in having lld be able to link against tbd files, and I think it'd be cool if libtool -static could write tbd files (similar to thin archives on linux) since that should make archiving much faster. Juergen, maybe uploading your initial patch to phabricator instead of attaching might get more traction? On Wed, Apr 25, 2018

I am getting assembler errors on clang-llvm-2.9 output for a program with exceptions that I do not get when using the installed g++ Mac OS-X 10.4 powerpc-apple-darwin > as -version Apple Computer, Inc. version cctools-590.23.2.obj~17, GNU assembler version 1.38 the folks at gnu-binutils assure me this is an assembler bug, but also that this isn't a recognizable "gnu"

Is this an extension to what cctools' assembler provides or a missing feature in MC? On 28 September 2013 18:48, Nicholas White <n.j.white at gmail.com> wrote: > Hi - I've attached a patch to make the assembly parser recognise the > .bss directive on Darwin targets as a switch to the (__DATA,__bss) > section. The ELF & COFF assembly parsers already recongnise the .bss

That sounds great to me, thanks Jake. I'm not Jurgen either, of course, but I'm happy to assist you if he is unavailable. I'm not also not qualified to audit the license, but do note Apple formally also released some code at https://opensource.apple.com/tarballs/tapi/. If there's anything else I can do to help, let me know. Cheers, John On 04/10/2018 06:13 PM, Jake Ehrlich

Great to hear, thanks! On Thu, Sep 20, 2018 at 1:56 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > A member of my team +Armando Montanez <amontanez at google.com> is going to > drop a proposal for the ELF part of this soon (like sometime next week) and > will be working on the implementation. I'll be one of the reviewers for > anything that comes out of that so