similar to: [LLVMdev] CLang/LLVM SVN for today no longer works on OS X 10.7.4

Hi Kent, My guess is you are getting some new bit of info in your object files and your 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

Here you go: http://www.cornwarning.com/xfer/jccolor.o (from the jpeg library...) jccolor.o: Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags MH_MAGIC_64 X86_64 ALL 0x00 OBJECT 4 432 SUBSECTIONS_VIA_SYMBOLS Load command 0 cmd LC_SEGMENT_64 cmdsize 312 segname vmaddr 0x0000000000000000 vmsize 0x0000000000000900

On Fri, Jun 2, 2017 at 2:34 PM, Ed Maste via llvm-dev < llvm-dev at lists.llvm.org> wrote: > One additional use case for you: converting from a binary to an ELF object > file > ``` > objcopy -I binary -O elf64-x86-64 foo.bin foo.o > ``` > This is sometimes used for embedding binary files for use by drivers and > such. > Yea, unfortunately the command-line you

Hi! I'm trying to build lld Microsoft Visual Studio 2012 RC, but it seems the bzero function is not available. Could memset be used instead of bzero? Or maybe define a bzero for msvc using memset. For example: // in-memory matches on-disk, so copy first fields followed by path ::memcpy(to, (uint8_t*)&cmd, 12); ::memcpy(&to[12], _name.data(), _name.size());

Hi All, I was wondering if someone could help illuminate me… I took a very simple objective-c file, "simple" and started looking at various sections… Finally I did… $otool -X -s __DATA __objc_selrefs simple 00003034 00002fec 00002fe7 00002fd7 00002fcc 00003044 00002fc6 00002ff2 $ otool -l simple | grep selrefs -A20 sectname __objc_selrefs segname __DATA addr 0x00003034

Fantastic! Thanks for all of the input! I'll be considering all of it going forward. The plan right now is just to worry about ELF executables and nothing else. I'm very sympathetic to the "llvm-objtool" change. If everyone is cool with it I'll change the name in the next CL to "llvm-objtool". To start out I implemented a very basic ELF64LE specific bit of code.

OK thanks a lot Michael Spencer! After getting your latest commit now everything compiles on Visual Studio 2012 RC. I'm just playing around to learn. Maybe this is the funniest place to start assessing my possibilities of contributing to llvm in the free time: Writer* createWriterPECOFF(const WriterOptionsPECOFF &options) { assert(0 && "PE/COFF support not implemented

On Sat, Jun 16, 2012 at 4:15 PM, Cesar Mello <cmello at gmail.com> wrote: > Hi! > > I'm trying to build lld Microsoft Visual Studio 2012 RC, but it seems the > bzero function is not available. > > Could memset be used instead of bzero? Or maybe define a bzero for msvc > using memset. > > For example: > >       // in-memory matches on-disk, so copy first

For example, I execute the following command sequences: H:\CI\bld\compilers\musl\src\math\i386>type sqrt.s #.globl _sqrt .global sqrt #.type sqrt, at function #_sqrt: sqrt: fldl 4(%esp) fsqrt fstsw %ax sub $12,%esp fld %st(0) fstpt (%esp) mov (%esp),%ecx and $0x7ff,%ecx cmp $0x400,%ecx jnz 1f and $0x200,%eax

I don't think we should attempt to mangle symbols declared in assembly source files. If you're writing assembly, you will need to handle ABI portability, including the _ prefix on win32 x86. clang will run the C preprocessor for you if you use the .S file suffix (case matters). On Tue, Oct 22, 2013 at 7:08 AM, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com>wrote: > For example, I

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

On Tue, Jun 6, 2017 at 11:14 PM, Michael Clark via llvm-dev < llvm-dev at lists.llvm.org> wrote: > OK. I see that the Mach-O linker is not even built when LLD is enabled in > Release_40, only the PE/COFF and ELF linkers are built. > > From looking at reviews it appears that Clang was able to be linked with > LLD on Darwin about 2 years ago, so Mach-O support seems to have

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:

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

I described this off-list to Zac, but for anyone else who is following, simply specifying the target triple is not enough to have the build system set an older macOS deployment target. I.e the 6.0.0-rc1 binaries I've just uploaded have the same deployment target problem. Looking at the 5.0.0 and 6.0.0-rc1 binaries, I can confirm that their deployment target was too new: Load command 9

On Jun 16, 2012, at 8:23 PM, Cesar Mello wrote: > While this will make it compile, the code is not valid to begin with. > It is trying to do a raw memory copy of a non standard-layout type. > nameoffset is not guaranteed to directly follow cmdsize. Are you saying that in: struct A { int f1; // offset 0 int f2; // offset 4 }; struct B : public A { int f3; // offset

How is -mmacosx-version-min=10.9 being set? LLVM_COMPILE_FLAGS? Or CMAKE_CXX_COMPILE? > On May 2, 2018, at 19:22, Vedant Kumar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I described this off-list to Zac, but for anyone else who is following, simply specifying the target triple is not enough to have the build system set an older macOS deployment target. I.e the 6.0.0-rc1

On Fri, Jun 30, 2017 at 5:54 PM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Problem > ------- > > Instrumentation for PGO and frontend-based coverage places a large amount > of > data in object files, even though the majority of this data is not needed > at > run-time. All the data is needlessly duplicated while generating archives, > and > again while

Hi Zac, Thanks for the heads-up. I've started targeting a minimum macOS deployment target of 10.9 for the release binaries. Hope this helps. Let me know if there are any issues. vedant > On May 1, 2018, at 4:13 PM, Zac Hansen via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The past few packages on http://releases.llvm.org/download.html

Hello Leslie, I don't know quite what to say as I don't know precisely what your question is? If I am not being precise enough please can you put some explicit questions in? From what I can see in the output, here are some comments. >From your arc mapfiles it looks like that in the output both linker's have given the .text output section the correct base address given the