search for: segname

...nwarning.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 fileoff 464 filesize 2304 maxprot rwx initprot rwx nsects 3 flags (none) Section sectname __text segname __TEXT addr 0x0000000000000000 size 0x00000000000006b6 offset 464 align 2^4 (16) reloff 2768...

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

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

...ormal object format? gcc main.c -Wl,-b -Wl,binary -Wl,picture.jpg -Wl,-b -Wl,<<something to undo binary mode?>> So, anyways, while this is _possible_ with objcopy, it'd sure be nice if you never needed to use it for that... (BTW, Apple ld actually has an option "-sectcreate SEGNAME SECTNAME INPUT_FILE", and the clang driver will pass it through to the linker.) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170602/2a354042/attachment.html>

...ring literal could bypass most of > the parsing overhead of a big array literal, but the people that care about > including a binary in their program probably don't care about that. > > -- Sean Silva > > >> >> (BTW, Apple ld actually has an option "-sectcreate SEGNAME SECTNAME >> INPUT_FILE", and the clang driver will pass it through to the linker.) >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev...

...d returned 1 exit status The code that generates this error (from ld.cpp) is here: template <typename A> void AnonymousAtom<A>::resolveName() { /*some code omitted*/ else if ( (strncmp(fSection->sectname(), "__objc_classrefs", 16) == 0) && (strcmp(fSection->segname(), "__DATA") == 0) ) { std::vector<ObjectFile::Reference*>& references = this->getReferences(); if ( references.size() != 1 ) throwf("__objc_classrefs element missing reloc (count=%ld) for target class in %s",...

...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 size 0x00000018 offset 8244 align 2^2 (4) reloff 0 nreloc 0 flags 0x10000005 reserved1 0 reserved2 0 Now, obviously these are where the selectors are, and sure enough when I start walking the disass I find these addresses coming up.. but i...

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

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

...OFILL, 0, - SectionKind::getBSS()), - Sym, Size, 1 << Pow2Alignment); - return false; - } - - Out.EmitCommonSymbol(Sym, Size, 1 << Pow2Alignment); - return false; -} - -/// ParseDirectiveDarwinZerofill -/// ::= .zerofill segname , sectname [, identifier , size_expression [ -/// , align_expression ]] -bool AsmParser::ParseDirectiveDarwinZerofill() { - StringRef Segment; - if (ParseIdentifier(Segment)) - return TokError("expected segment name after '.zerofill' directive"); - - if (Lexer.isNot(Asm...

LLVM already implements its own version of almost all of binutils. The exceptions to this rule are objcopy and strip. This is a proposal to implement an llvm version of objcopy/strip to complete llvm’s binutils. Several projects only use gnu binutils because of objcopy/strip. LLVM itself uses objcopy in fact. Chromium and Fuchsia currently use objcopy as well. If you want to distribute your build

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 linking. PGO name data is written out into raw profiles by instrumented programs, slowing down the training and code coverage workflows.