search for: sht_note

...MipsReginfoSection, MipsOptionsSection classes. If > you need to copy sections from input to output, use SDataSection (from > Hexagon) as a reference point. > Hi Simon, Thanks for the reply. I have a few more follow up questions. ELFFile::handleSectionWithNoSymbols() returns false for SHT_NOTE. This means that ELFFile::createAtoms() never creates an atom for .note sections. It seems like even if I use something like SDataSection, then I will still need to modify ELFFIle::handleSectionWithNoSymbols(). What is the best way to do this? Should I make the function virtual and override it i...

Hi, I'm working on an AMDGPU target for lld, and I'm trying to link a single .o file with a .note section, but the .note section is missing from the resulting a.out file. How can I control which sections get copied over to the executable? Is there a target hook to implement? Thanks, Tom

...is inline with what I was suggesting as a second mechanism for this that could be designed. But, again, that is beyond the scope of the changes that I am proposing. > (also, do you know if the COFF/MachO representation for the linker > options in the .o file can/cannot be dropped? AFAIK, SHT_NOTE can be > ignored) > Well, the content is only in the object files. The final linked binary does not contain it (which is why Im abusing the SHT_NOTE). Do you mean does the linker ignore it? Well, if the linker doesn't support the feature, it would. In PE/COFF, it is encoded as a spec...

...we may want to move away from llvm.linker.options. For example, we could let frontends parse legacy open-ended linker pragmas and emit a new IR format with constrained semantics. (also, do you know if the COFF/MachO representation for the linker options in the .o file can/cannot be dropped? AFAIK, SHT_NOTE can be ignored) I just find it very fishy to consider linker options as advisory. Presumably if a user is passing them, then they are required for correctness. -- Sean Silva > > This allows for the backend to be entirely oblivious to the data as the > other backends and allows for ext...

...; ELF support, via the "obj2yaml" and "yaml2obj" tools.) I'd note that reproducing all the things that are required/used from an ELF shared object during linking -- symbol type, binding-type, visibility, version, alignment (!), .gnu.warning messages, various important "SHT_NOTE" sections, and whatever other things I've forgotten about, will need to be a _significantly_ different format than what Apple has as their "TBD" format. Apple's format also has a bunch of special cases in it to make it easier to use for their platform, but a rather less gener...

...******************************************************************** + * elfnote.h + * + * Definitions used for the Xen ELF notes. + * + * Copyright (c) 2006, Ian Campbell, XenSource Ltd. + */ + +#ifndef __XEN_PUBLIC_ELFNOTE_H__ +#define __XEN_PUBLIC_ELFNOTE_H__ + +/* + * The notes should live in a SHT_NOTE segment and have "Xen" in the + * name field. + * + * Numeric types are either 4 or 8 bytes depending on the content of + * the desc field. + * + * LEGACY indicated the fields in the legacy __xen_guest string which + * this a note type replaces. + */ + +/* + * NAME=VALUE pair (string). +...

...e that this would be a very useful addition to ELF. I've always wanted to reach the point where you could just type "ld main.o" and have all the dependencies automatically linked in. (Go kind of achieves this, I think.) I'm not in favor of using yet another note section, however. SHT_NOTE sections are intended for the use of "off-axis" tools, not for something the linker would need to look for. I don't want to have the linker parsing individual note entries looking for notes of interest to itself, and then having to decide whether to edit those entries out of the large...

...re you could just type "ld main.o" and > have all the dependencies automatically linked in. (Go kind of > achieves this, I think.) Excellent! I think that everyone agrees that this is a useful extension to add. > I'm not in favor of using yet another note section, however. SHT_NOTE > sections are intended for the use of "off-axis" tools, not for > something the linker would need to look for. I don't want to have the > linker parsing individual note entries looking for notes of interest > to itself, and then having to decide whether to edit those entr...

...the point where you could just type "ld main.o" and have all the dependencies automatically linked in. (Go kind of achieves this, I think.) Excellent! I think that everyone agrees that this is a useful extension to add. I'm not in favor of using yet another note section, however. SHT_NOTE sections are intended for the use of "off-axis" tools, not for something the linker would need to look for. I don't want to have the linker parsing individual note entries looking for notes of interest to itself, and then having to decide whether to edit those entries out of the large...

Hello all, There was some interest from a number of a few people about adding support for embedded linker options to ELF. This would be an extension that requires linker support to actually work, but has significant prior art with PE/COFF as well as MachO both having support for this. The desire here is to actually add support to LLVM to pass along the necessary information into the object

...t;ld main.o" and >> have all the dependencies automatically linked in. (Go kind of >> achieves this, I think.) > > Excellent! I think that everyone agrees that this is a useful extension to add. > >> I'm not in favor of using yet another note section, however. SHT_NOTE >> sections are intended for the use of "off-axis" tools, not for >> something the linker would need to look for. I don't want to have the >> linker parsing individual note entries looking for notes of interest >> to itself, and then having to decide whether to...

...if (STM.dumpCode()) { > +#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) > + MF.dump(); > +#endif > + > + if (DisasmEnabled) { > + OutStreamer.SwitchSection(Context.getELFSection(".AMDGPU.disasm", > + ELF::SHT_NOTE, 0, > + SectionKind::getReadOnly())); > + > + for (size_t i = 0; i < DisasmLines.size(); ++i) { > + std::string Comment(DisasmLineMaxLen - DisasmLines[i].size(), ' '); > + Comment += " ; " + HexL...

Hi, This patch adds R600/SI disassembly text to compiled object files, when a code dump is requested, to assist debugging in Mesa clients. Here's an example of the output in a Mesa client with a corresponding patch and RADEON_DUMP_SHADERS set: Shader Disassembly: S_WQM_B64 EXEC, EXEC ; BEFE0A7E S_MOV_B32 M0, SGPR6 ; BEFC0306

...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 + WARN_ON(szdynsym...

...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 + WARN_ON(szdynsym...

...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 + WARN_ON(szdynsym...

Benifits of TBD: 1) It's human readable and diffs on TBDs correspond to changes in the ABI. Diffs can be automatically added to review processes to ensure that changes to the ABI are reviewed. The TBDs also document your precise ABI. 2) The size is smaller which means they can be shipped in an SDK instead of binaries to reduce the size of an SDK 3) Stubs are producible from TBDs (or should be)

On Mon, Apr 9, 2018 at 10:11 PM, John Ericson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > Regardless of any of that, given that TBD files _are_ an integral part > of the apple platform, supporting them is certainly a necessity in order to > have a working apple linker. So, if making LLD work for Apple/MachO is the > justification for adding TBD support to LLVM, that

On Fri, Jan 5, 2018 at 2:30 AM Rui Ueyama <ruiu at google.com> wrote: > Thank you for starting the discussion thread. > > In general I'm in favor of the proposal. Defining a generic way to convey > some information from the compiler to the linker is useful, and it looks > like it is just a historical reason that the ELF lacks the feature at the > moment. > > This

Hi James, Thank you for the comments. >I think we're not terribly far from that ideal, now, for ELF. Maybe only these three things need to be done? -- >  1. Teach lld how to emit a separated debuginfo output file directly, without requiring an objcopy step. >  2. Integrate DWARFLinker into lld. >  3. Create a new tool which takes the separated debuginfo and DWO/DWP files