search for: shf_alloc

...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 in AMDGPUELFFile.cpp? In ELFDefinedAtom::doContentType(), SHT_NOTE sections are only assigned the typeR[OW]Note ContentType if they have the SHF_ALLOC flag. This is because any section without SHF_ALLOC is assigned the typeNoAlloc ContentType before the section type is ever considered. Is this a bug or are SHT_NOTE sections required to have the SHF_ALLOC flag? Thanks, Tom > On Sat, Jun 13, 2015 at 6:28 AM, Tom Stellard <tom at stellard....

On Sep 16, 2013, at 6:48 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Michael, > On 9/16/2013 7:23 PM, Michael Spencer wrote: >> Debug info linking is currently broken due to how we handle reading and >> laying out non SHF_ALLOC sections. I posted a patch that partially fixes >> this, but it's both the wrong approach and doesn't handle multiple input >> files with debug info (wrong relocation values). >> >> The first issue is representing non SHF_ALLOC atoms in the Atom model. We >> c...

Debug info linking is currently broken due to how we handle reading and laying out non SHF_ALLOC sections. I posted a patch that partially fixes this, but it's both the wrong approach and doesn't handle multiple input files with debug info (wrong relocation values). The first issue is representing non SHF_ALLOC atoms in the Atom model. We currently don't have a type for this, and...

Hi Michael, On 9/16/2013 7:23 PM, Michael Spencer wrote: > Debug info linking is currently broken due to how we handle reading and > laying out non SHF_ALLOC sections. I posted a patch that partially fixes > this, but it's both the wrong approach and doesn't handle multiple input > files with debug info (wrong relocation values). > > The first issue is representing non SHF_ALLOC atoms in the Atom model. We > currently don't ha...

On Mon, Sep 16, 2013 at 6:48 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Hi Michael, > > > On 9/16/2013 7:23 PM, Michael Spencer wrote: > >> Debug info linking is currently broken due to how we handle reading and >> laying out non SHF_ALLOC sections. I posted a patch that partially fixes >> this, but it's both the wrong approach and doesn't handle multiple input >> files with debug info (wrong relocation values). >> >> The first issue is representing non SHF_ALLOC atoms in the Atom model. We >> cu...

...to add/remove sections after parsing a binary and re-write the binary to another location. Basically, like what llvm-objcopy does. Can you point me to the right classes to look into, if this is something that LLVM has? >> >> Many thanks >> >> Joseph For ELF, * adding a non-SHF_ALLOC section is simple. A non-SHF_ALLOC section is not part of the memory image and not used by the program (unless for some rare introspection use cases) * adding a SHF_ALLOC section is difficult. You likely need to fix the containing PT_LOAD segment. llvm-objcopy only does the base p_offset...

On Mon, Sep 16, 2013 at 8:23 PM, Michael Spencer <bigcheesegs at gmail.com>wrote: > Debug info linking is currently broken due to how we handle reading and > laying out non SHF_ALLOC sections. I posted a patch that partially fixes > this, but it's both the wrong approach and doesn't handle multiple input > files with debug info (wrong relocation values). > > The first issue is representing non SHF_ALLOC atoms in the Atom model. We > currently don't ha...

The ELF file header isn't always covered by a segment but still affects loading. I think everything else that effects loading/dynamic linking is always covered by a PT_LOAD segment. As evidence this is basically what --strip-sections in llvm-strip and eu-strip do and they produce perfectly runnable binaries. Having a hash of the actual memory map is interesting IMO. Build IDs can't really

...l list "Relocation Sections" with "Relocation Section" entries. But I think this solution is a little bit over designed. Any objections / suggestions? [[ Sections: - Name: .text Type: SHT_PROGBITS Content: "0000000000000000" AddressAlign: 16 Flags: [SHF_ALLOC] - Name: .rel.text Type: SHT_REL Info: .text AddressAlign: 4 Relocations: - !Relocation Offset: 0x1 SymbolName: glob1 Type: R_MIPS_32 - !Relocation Offset: 0x2 SymbolName: glob2 Type: R_MIPS_CALL16 ]] -- Simon Atanasya...

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

Hey, LLVM has logic to parse ELF and PE binaries using `llvm::object::createBinary`. I tried to search in the codebase to see if there's a possibility to add/remove sections after parsing a binary and re-write the binary to another location. Basically, like what llvm-objcopy does. Can you point me to the right classes to look into, if this is something that LLVM has? Many thanks Joseph

...t unnamed segment > ; Range: [0x5c; 0x64[ (8 bytes) > ; File offset : [144; 152[ (8 bytes) > ; Permissions: - > > ; Section .data.test > ; Range: [0x5c; 0x60[ (4 bytes) > ; File offset : [144; 148[ (4 bytes) > ; Flags: 0x3 > ; SHT_PROGBITS > ; SHF_WRITE > ; SHF_ALLOC > > test: > > 0000005c dd 0x00000063 > > ; Section .data.unused > ; Range: [0x60; 0x64[ (4 bytes) > ; File offset : [148; 153[ (4 bytes) > ; Flags: 0x3 > ; SHT_PROGBITS > ; SHF_WRITE > ; SHF_ALLOC > > unused: > > 000000...

...While the api3() function is correctly gone, the result for the C-string is the following (in Hopper): > ; Section .rodata.str1.1 > > ; Range: [0x63; 0x6f[ (12 bytes) > > ; File offset : [151; 163[ (12 bytes) > > ; Flags: 0x32 > > ; SHT_PROGBITS > > ; SHF_ALLOC > > .L.str: > > 00000063 db "Test", 0 > > .L.str.1: > > 00000068 db "Unused", 0 Links: ------ [1] https://github.com/llvm/llvm-project/blob/master/llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp#L799 ---------...

...rom multiple loadable partitions are allocated to the main partition even if they aren’t reachable from the main partition. When assigning input sections to output sections, we take into account, in addition to the name of the input section, the partition that the input section is assigned to. The SHF_ALLOC output sections are first sorted by partition, and then by the usual sorting rules. As usual, non-SHF_ALLOC sections appear last and are not sorted by partition. In the end we are left with a collection of output sections that might look like this: Main partition: 0x0000 ELF header, phdrs 0x1000 ....

...Backend, but we currently + // have no way to reach it. + bool IsThumb; + int64_t MappingSymbolCounter; /// @} void SetSection(StringRef Section, unsigned Type, unsigned Flags, SectionKind Kind) { @@ -130,18 +139,21 @@ private: ELF::SHF_WRITE |ELF::SHF_ALLOC, SectionKind::getDataRel()); EmitCodeAlignment(4, 0); + EmitMappingSymbol(/*IsData*/true); } void SetSectionText() { SetSection(".text", ELF::SHT_PROGBITS, ELF::SHF_EXECINSTR | ELF::SHF_ALLOC, SectionKind::getText());...

...ed to the main partition even if >> they aren’t reachable from the main partition. >> >> When assigning input sections to output sections, we take into account, >> in addition to the name of the input section, the partition that the input >> section is assigned to. The SHF_ALLOC output sections are first sorted by >> partition, and then by the usual sorting rules. As usual, non-SHF_ALLOC >> sections appear last and are not sorted by partition. In the end we are >> left with a collection of output sections that might look like this: >> >> Main...

...mbinfo.syms.e.num = eh64->e_shnum; + mbinfo.syms.e.size = eh64->e_shentsize; + mbinfo.syms.e.shndx = eh64->e_shstrndx; + + for (i = 0; i < eh64->e_shnum; i++) { + addr_t align; + + if (!sh64[i].sh_size) + continue; /* Empty section */ + if (sh64[i].sh_flags & SHF_ALLOC) + continue; /* SHF_ALLOC sections should have PHDRs */ + + align = sh64[i].sh_addralign ? sh64[i].sh_addralign : 0; + addr = map_data((char *)ptr + sh64[i].sh_offset, + sh64[i].sh_size, align, MAP_HIGH); + if (!addr) { + error("Failed to map symbol section\n"); + re...

Hello, I'm currently looking into integrating the patchpoint and stackmap intrinsics into my pet project. In their current implementation (3.4 and trunk) the code to emit the additional section is only executed on Darwin. This is however quickly fixed: Add a ".llvm_stackmaps"-Section for ELF in MCObjectFileInfo and execute StackMaps::serializeToStackMapSection in X86AsmPrinter in

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

...n is a little bit over > > designed. > > > > Any objections / suggestions? > > > > [[ > > Sections: > > - Name: .text > > Type: SHT_PROGBITS > > Content: "0000000000000000" > > AddressAlign: 16 > > Flags: [SHF_ALLOC] > > > > - Name: .rel.text > > Type: SHT_REL > > Info: .text > > AddressAlign: 4 > > Relocations: > > - !Relocation > > Offset: 0x1 > > SymbolName: glob1 > > Type: R_MIPS_32 > > -...