search for: cctool

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

...cently there has been some progress on LLVM-based tools for manipulating MachO binaries: llvm-objcopy has been gaining a lot of important bits to support MachO (it's relatively close to the point where one can implement the strip-like functionality), llvm-lipo is functional and supports most of cctools' lipo options (https://llvm.org/docs/CommandGuide/llvm-lipo.html). There is another useful utility called install_name_tool (see e.g. https://www.unix.com/man-page/osx/1/install_name_tool/ ), this tool is capable of changing the rpaths, the names of the dependent shared libraries, etc. The way...

...dyld_priv.h. >> >> I'm doing my best to stitch it all together, but if anyone has any pointers to make this less painful, it would be much obliged. > > Most of the stuff on opensource.apple.com is very painful to build. In this case you have to pick up reloc.h from > the cctools archive and dyld_priv.h from dyld. > > http://opensource.apple.com/source/cctools/cctools-806/include/mach-o/arm/reloc.h > http://opensource.apple.com/source/dyld/dyld-195.5/include/mach-o/dyld_priv.h > > put them in the right directories and it should compile. > > - Ben &g...

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: > https://sourceware.org/binutils/docs/as/ARM-Directives.html . Supporting the > direc...

*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. Therefore, similarly to llvm-strip and llvm-inst...

Ben, Thanks for your help! > http://opensource.apple.com/source/cctools/cctools-806/include/mach-o/arm/reloc.h Yep, as Joe Ranieri pointed out, I had to tell MachOFileAbstraction.hpp about ARM relocs > http://opensource.apple.com/source/dyld/dyld-195.5/include/mach-o/dyld_priv.h I tried to use the dyld_priv.h from cctools to no avail, using the one from dyld (as...

...mach-o/arm/reloc.h, and dyld_priv.h. > > I'm doing my best to stitch it all together, but if anyone has any pointers to make this less painful, it would be much obliged. Most of the stuff on opensource.apple.com is very painful to build. In this case you have to pick up reloc.h from the cctools archive and dyld_priv.h from dyld. http://opensource.apple.com/source/cctools/cctools-806/include/mach-o/arm/reloc.h http://opensource.apple.com/source/dyld/dyld-195.5/include/mach-o/dyld_priv.h put them in the right directories and it should compile. - Ben > Humbly, > > Joe Abbey &g...

...n some progress on LLVM-based tools for manipulating > MachO binaries: llvm-objcopy has been gaining a lot of important bits to > support MachO (it's relatively close to the point where one can implement > the strip-like functionality), llvm-lipo is functional and supports most of > cctools' lipo options (https://llvm.org/docs/CommandGuide/llvm-lipo.html > ). > There is another useful utility called install_name_tool (see e.g. > https://www.unix.com/man-page/osx/1/install_name_tool/ ), > this tool is capable of changing the rpaths, the names of the dependent > shar...

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 it all together, but if anyone has any pointers to make this less painful, it would be

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

...[test-all-basics] Error 1 make: *** [check-all] Error 2 I am not sure what does this mean. One potentially related issue is that, I downloaded and installed a gfortran compiler: GNU Fortran 95 (GCC) 4.2.0 20060512 (experimental), because we don??t have one originally. But I didn??t use the latest cctools, and our version is: Apple Computer, Inc. version cctools-590.23.2.obj~17. Not sure whether this matters. Our gcc compiler is: powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5250). Please let me know if you have any idea about it. Thank you. Weijun

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 directive. I've added a test case for it too. Thanks - Nick -------------- next part -------------- A non-text attachment was scrubbed... Name: bss.patch Type:

...ranlib(1) is older and doesn't know about it. If you can send me the .o file or the output of otool(1) with the -hlv options on your object file I can take a look. Kev P.S. you can find out the version of ranlib(1) you have by running strings(1) on it and grep(1)'ing for the string "cctools". On Sep 26, 2012, at 2:19 PM, Kent Williams wrote: > Ran into this today -- rebuilt the SVN Trunk for this morning of > LLVM+CLANG. Now every time my builds try and make a library from .o > files, ranlib complains about 'malformed object' files. > > This is with OS...

...d? Nick On 30 September 2013 13:50, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > 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: >> https://sourceware.org/binutils/docs/as/ARM-Directives.html . Supporting th...

...ular 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 binaries this would enable us to build LLVM-based replacements for cctools' install_name_tool (for changing rpath(s), identification name etc) and lipo / libtool (for manipulating "fat" binaries) similarly to how llvm-strip was implemented on top of llvm-objcopy. Regarding the code organization, probably, in this case we will have separate folders: ELF, Mac...

Ran into this today -- rebuilt the SVN Trunk for this morning of LLVM+CLANG. Now every time my builds try and make a library from .o files, ranlib complains about 'malformed object' files. This is with OS X 10.7.4, and the binary tools from XCode 4.4.1 ld -v @(#)PROGRAM:ld PROJECT:ld64-127.2 llvm version 3.0svn, from Apple Clang 3.0 (build 211.12) ranlib doesn't tell you what

...nd (52) (Producer: 'LLVM3.9.0' Reader: 'LLVM APPLE_1_800.0.42.1_0') /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar: internal ranlib command failed Using MacPorts, I've been able to confirm that archiving LTO object files now requires a cctools release that has been built against llvm 3.9.0 rather than 3.8.1 to avoid this failure. Was this change intentional and is there any possibility of restoring compatibility with the currently shipping Xcode releases? Jack

I'm working on bringing up a buildbot in the LLVM lab that would run the GCC and GDB DejaGNU tests. The current problem I'm running into is shown here: http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb-gcc/builds/323/steps/install.clang.stage1/logs/stdio When the buildbot attempts to "make install" the system 'strip' binary fails while attempting to strip the

...gt;> 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 binaries this would enable us to build LLVM-based >> replacements for cctools' install_name_tool (for changing rpath(s), >> identification name etc) and lipo / libtool (for manipulating "fat" >> binaries) similarly to how llvm-strip was implemented on top of >> llvm-objcopy. Regarding the code organization, probably, in this case we >>...

Hi all, libLTO is exposing a very “stable” (in the sense of immutable) C API to be used by linkers (and binutils tools) that manipulate bitcode (like when performing LTO). I’m looking into relaxing the stability concern and design a policy for this API that would allow to deprecate and remove some the APIs exposed here. The MacOS linker (ld64) is one the users of libLTO, but there are others