search for: sht_nobit

...quot; + getELFSectionTypeName(config->emachine, isec->type) + "\n>>> output section " + name + ": " + getELFSectionTypeName(config->emachine, type)); type = SHT_PROGBITS; } } if (noload) type = SHT_NOBITS; However, having said that, I think the following fix (although not the cleanest nor addresses any shortcommings in other parts of the code)  seems to fix my issue. https://reviews.llvm.org/D76981 I'm also hoping to get involve in the LLVM development in near future..... regards Kasun...

...the default output section type in the past.     Differential Revision: https://reviews.llvm.org/D60131     llvm-svn: 358981 commit 5929553868ddfd3f53672253782260c2a0a52c79 Author: Fangrui Song <maskray at google.com> Date:   Wed Apr 24 14:44:07 2019 +0000     [ELF] Delete a redundant SHT_NOBITS -> SHT_PROGBITS after D60131     Differential Revision: https://reviews.llvm.org/D61006     llvm-svn: 359099 What was the intention behind "Andrew Ng"'s commit? was it an oversight to set PROGBITS attribute unconditionally for sections that are allocation only? regards...

I am linking a program to be loaded in an ARM Cortex-M0+ based microcontroller. In the linker script, I have a section allocated for the stack which roughly looks like the following. .stack : { . += __stack_size__; } > ram Using the linker in the gcc arm toolchain, arm-none-eabi-ld, this section is automatically set to type NOBITS, however, when linking with version 10.0.0 of ld.lld, the

For those that are interested, I have attached the latest version of my Win32 COFF support patch. There is no new functionality, I just fixed some compiler errors due to recent changes in the MC library. - Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100527/23598d23/attachment.html>

...just fixed some > compiler errors due to recent changes in the MC library. One more review comment: + bool isVirtualSection(const MCSection &Section) const { +// const MCSectionCOFF &SE = static_cast<const MCSectionCOFF&>(Section); +// return SE.getType() == MCSectionCOFF::SHT_NOBITS; + + return false; // not sure how to interpret this right now + } Please get rid of the commented-out code and make the comment use FIXME so it's clear there's an issue here. -Eli

Hello All, In ARM embedded applications, there are some compilers that support useful function and variable attributes that help the compiler communicate information about symbols to downstream object consumers (i.e. linkers). One such attribute is the "location" attribute. This attribute can be applied to a global or local static data object or a function to indicate to the linker

...not want these in the same section so this mapped quite well to something similar to __attribute__((section(name))). - We did find some properties of __attribute__((section("name"))) inconvenient, especially that variables would come out as SHT_PROGBITS when in many cases the user wanted SHT_NOBITS (memory mapped peripheral), we had our custom attribute fix that. If you used a section name rather than a symbol then you may not need any backend changes and it would generalise over all ELF targets. Linker support is another question entirely though. Peter > > > The anticipated next...

Hi Ed, I wrote http://reviews.llvm.org/D10952 to address your last problem. There is also the related http://reviews.llvm.org/D10918 by Denis to address how you can directly assign sections to segments in the script. Both are in code review. Rafael auelr On Fri, Jul 3, 2015 at 12:29 AM, Rafael Auler <rafaelauler at gmail.com> wrote: > Hi Ed, > > It looks like lld is failing at

...he same section so this mapped quite well to something similar to __attribute__((section(name))). - We did find some properties of __attribute__((section("name"))) inconvenient, especially that variables would come out as SHT_PROGBITS when in many cases the user wanted SHT_NOBITS (memory mapped peripheral), we had our custom attribute fix that. If you used a section name rather than a symbol then you may not need any backend changes and it would generalise over all ELF targets. Linker support is another question entirely though. Peter > &g...

...onText() { SetSection(".text", ELF::SHT_PROGBITS, ELF::SHF_EXECINSTR | ELF::SHF_ALLOC, SectionKind::getText()); EmitCodeAlignment(4, 0); + EmitMappingSymbol(/*IsData*/false); } void SetSectionBss() { SetSection(".bss", ELF::SHT_NOBITS, ELF::SHF_WRITE | ELF::SHF_ALLOC, SectionKind::getBSS()); EmitCodeAlignment(4, 0); + EmitMappingSymbol(/*IsData*/true); } }; } @@ -188,6 +200,55 @@ void MCELFStreamer::EmitThumbFunc(MCSymbol *Func) { MCSymbolData &SD = getAssembler().getOrCreate...

...ls = sechdrs[i].sh_size / sizeof(Elf64_Rela); + + if (sechdrs[i].sh_type != SHT_RELA) + continue; + + /* sort by type, symbol index and addend */ + sort(rels, numrels, sizeof(Elf64_Rela), cmp_rela, NULL); + + gots += count_gots(syms, rels, numrels); + } + + mod->arch.core.got->sh_type = SHT_NOBITS; + mod->arch.core.got->sh_flags = SHF_ALLOC; + mod->arch.core.got->sh_addralign = L1_CACHE_BYTES; + mod->arch.core.got->sh_size = (gots + 1) * sizeof(u64); + mod->arch.core.got_num_entries = 0; + mod->arch.core.got_max_entries = gots; + + /* + * If a _GLOBAL_OFFSET_TABLE_...

Attached is an example of how to reproduce the issue. It uses a C file that happens to has a bunch of switch statements which are encoded as jump tables, giving us data-in-code. Usage: To build object files with clang via the -integrated-as versus via GCC: $ export NDK_DIR=<my_ndk_dir> $ export LLVM_DIR=<my_llvm_bin_dir> $ make To test that the generated objects contain the same

Hi guys, I have attached my patch to support generating win32 COFF object files. I would have posted earlier, but my system drive crashed and I had to rebuild my system; Luckily, my source code was on a secondary drive. I think this would be a good beginning for ongoing support of the COFF object file format and was hoping for some feedback as to whether it was commit worthy or what was needed to

...gt;e_shnum; ++i) { + Elf32_Shdr *shdr = (void *)((unsigned long)ehdr + ehdr->e_shoff + i * ehdr->e_shentsize); + + if (!(shdr->sh_flags & SHF_ALLOC)) + continue; + shdr->sh_addr += new_base - old_base; + switch(shdr->sh_type) { + case SHT_DYNAMIC: + case SHT_HASH: + case SHT_NOBITS: + case SHT_NOTE: + case SHT_PROGBITS: + case SHT_STRTAB: + case 0x6ffffffd: /* SHT_GNU_verdef */ + case 0x6fffffff: /* SHT_GNU_versym */ + break; + case SHT_DYNSYM: + BUG_ON(shdr->sh_entsize < sizeof(Elf32_Sym)); + if (!szdynsym) + szdynsym = shdr->sh_entsize; + else +...

...gt;e_shnum; ++i) { + Elf32_Shdr *shdr = (void *)((unsigned long)ehdr + ehdr->e_shoff + i * ehdr->e_shentsize); + + if (!(shdr->sh_flags & SHF_ALLOC)) + continue; + shdr->sh_addr += new_base - old_base; + switch(shdr->sh_type) { + case SHT_DYNAMIC: + case SHT_HASH: + case SHT_NOBITS: + case SHT_NOTE: + case SHT_PROGBITS: + case SHT_STRTAB: + case 0x6ffffffd: /* SHT_GNU_verdef */ + case 0x6fffffff: /* SHT_GNU_versym */ + break; + case SHT_DYNSYM: + BUG_ON(shdr->sh_entsize < sizeof(Elf32_Sym)); + if (!szdynsym) + szdynsym = shdr->sh_entsize; + else +...

...gt;e_shnum; ++i) { + Elf32_Shdr *shdr = (void *)((unsigned long)ehdr + ehdr->e_shoff + i * ehdr->e_shentsize); + + if (!(shdr->sh_flags & SHF_ALLOC)) + continue; + shdr->sh_addr += new_base - old_base; + switch(shdr->sh_type) { + case SHT_DYNAMIC: + case SHT_HASH: + case SHT_NOBITS: + case SHT_NOTE: + case SHT_PROGBITS: + case SHT_STRTAB: + case 0x6ffffffd: /* SHT_GNU_verdef */ + case 0x6fffffff: /* SHT_GNU_versym */ + break; + case SHT_DYNSYM: + BUG_ON(shdr->sh_entsize < sizeof(Elf32_Sym)); + if (!szdynsym) + szdynsym = shdr->sh_entsize; + else +...

...well to something similar to > > __attribute__((section(name))). > > - We did find some properties of __attribute__((section("name"))) > > inconvenient, especially that variables would come out as SHT_PROGBITS > > when in many cases the user wanted SHT_NOBITS (memory mapped > > peripheral), we had our custom attribute fix that. > > > > If you used a section name rather than a symbol then you may not need > > any backend changes and it would generalise over all ELF targets. > > Linker support is another ques...

...well to something similar to > > __attribute__((section(name))). > > - We did find some properties of __attribute__((section("name"))) > > inconvenient, especially that variables would come out as SHT_PROGBITS > > when in many cases the user wanted SHT_NOBITS (memory mapped > > peripheral), we had our custom attribute fix that. > > > > If you used a section name rather than a symbol then you may not need > > any backend changes and it would generalise over all ELF targets. > > Linker support is another ques...

...gt; __attribute__((section(name))). >> > > - We did find some properties of __attribute__((section("name"))) >> > > inconvenient, especially that variables would come out as >> SHT_PROGBITS >> > > when in many cases the user wanted SHT_NOBITS (memory mapped >> > > peripheral), we had our custom attribute fix that. >> > > >> > > If you used a section name rather than a symbol then you may not >> need >> > > any backend changes and it would generalise over all ELF targets....

...r to > > > __attribute__((section(name))). > > > - We did find some properties of __attribute__((section("name"))) > > > inconvenient, especially that variables would come out as > SHT_PROGBITS > > > when in many cases the user wanted SHT_NOBITS (memory mapped > > > peripheral), we had our custom attribute fix that. > > > > > > If you used a section name rather than a symbol then you may not > need > > > any backend changes and it would generalise over all ELF targets. > > >...