search for: sectnam

Hi Sanjiv, The PIC16TargetAsmInfo::getBSSSectionForGlobal apparently does magic that reinterprets the "section" field of a global in a strange way: // If GV has a sectin name or section address create that section now. if (GV->hasSection()) { std::string SectName = GV->getSection(); // If address for a variable is specified, get the address and create // section. std::string AddrStr = "Address="; if (SectName.compare(0, AddrStr.length(), AddrStr) == 0) { std::string SectAddr = SectName.substr(AddrStr.length());...

...The PIC16TargetAsmInfo::getBSSSectionForGlobal apparently does magic > that reinterprets the "section" field of a global in a strange way: > > // If GV has a sectin name or section address create that section > now. > if (GV->hasSection()) { > std::string SectName = GV->getSection(); > // If address for a variable is specified, get the address and > create > // section. > std::string AddrStr = "Address="; > if (SectName.compare(0, AddrStr.length(), AddrStr) == 0) { > std::string SectAddr = SectName.s...

...C_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 nreloc 9 type S_REGULAR attributes PURE_INSTRUCTIONS SOME_INSTRUCTIONS reserved1 0 reserved2 0 Section sectname __compact_unwind segname __LD...

...nfo::getBSSSectionForGlobal apparently does magic >> that reinterprets the "section" field of a global in a strange way: >> >> // If GV has a sectin name or section address create that section >> now. >> if (GV->hasSection()) { >> std::string SectName = GV->getSection(); >> // If address for a variable is specified, get the address and >> create >> // section. >> std::string AddrStr = "Address="; >> if (SectName.compare(0, AddrStr.length(), AddrStr) == 0) { >> std::string Se...

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

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

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

...c0)* 0x00000c50 0x00000040 0x00000000 JIT(0x7fc4230f4e00).__LD > 0x00000008 regular [0x0000000112efce80-0x0000000112efcec0) 0x00000c50 0x00000040 0x02000000 JIT(0x7fc4230f4e00).__LD.__compact_unwind > > (the relocated address is > > julia> datapointer(filter(s->s.sectname == "__debug_info",sects)[1]) > Ptr{Uint8} @0x0000000112efcd68 > > ) > > so it seems like despite knowing the correct load address for the __debug_info section, it's still somehow picking up on the old addresses. I'll keep looking, but if something springs to mind...

...t class in /var/folders/q7/q7f3KCNoGkOtsKthZvb6LJWOlJU/-Tmp-//ccjnT818.o collect2: ld 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(&q...

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

I didn't get to work on this more last week, but I'll look at incorporating that suggestion. The other question of course is how to do this in LLDB. Right, now what I'm doing is going through and adjusting the load address of every leaf in the section tree. That basically works and gets me backtraces with the correct function names and the ability to set breakpoints at functions in

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

...- 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(AsmToken::Com...

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.