search for: sht_progbit

On Mon, Nov 16, 2020 at 10:42 PM Igor Kudrin <ikudrin at accesssoftek.com> wrote: > > On 14.11.2020 3:42, Fāng-ruì Sòng wrote: > > For .debug_* in object files: > > > > DWARF32 -> SHT_PROGBITS (unchanged) > > DWARF64 -> SHT_DWARF64 or SHT_GNU_DWARF64 > > > > In LLD, we will need to allow mixed SHT_PROGBITS and SHT_DWARF64. If > > all input sections are SHT_DWARF64, the output section type probably > > should also be SHT_DWARF64. > > If mixed, SHT_P...

...t google.com> wrote: >> >> On Mon, Nov 16, 2020 at 10:42 PM Igor Kudrin <ikudrin at accesssoftek.com> wrote: >> > >> > On 14.11.2020 3:42, Fāng-ruì Sòng wrote: >> > > For .debug_* in object files: >> > > >> > > DWARF32 -> SHT_PROGBITS (unchanged) >> > > DWARF64 -> SHT_DWARF64 or SHT_GNU_DWARF64 >> > > >> > > In LLD, we will need to allow mixed SHT_PROGBITS and SHT_DWARF64. If >> > > all input sections are SHT_DWARF64, the output section type probably >> > > should a...

...Fāng-ruì Sòng <maskray at google.com> wrote: > On Mon, Nov 16, 2020 at 10:42 PM Igor Kudrin <ikudrin at accesssoftek.com> > wrote: > > > > On 14.11.2020 3:42, Fāng-ruì Sòng wrote: > > > For .debug_* in object files: > > > > > > DWARF32 -> SHT_PROGBITS (unchanged) > > > DWARF64 -> SHT_DWARF64 or SHT_GNU_DWARF64 > > > > > > In LLD, we will need to allow mixed SHT_PROGBITS and SHT_DWARF64. If > > > all input sections are SHT_DWARF64, the output section type probably > > > should also be SHT_DWARF64....

On 14.11.2020 3:42, Fāng-ruì Sòng wrote: > For .debug_* in object files: > > DWARF32 -> SHT_PROGBITS (unchanged) > DWARF64 -> SHT_DWARF64 or SHT_GNU_DWARF64 > > In LLD, we will need to allow mixed SHT_PROGBITS and SHT_DWARF64. If > all input sections are SHT_DWARF64, the output section type probably > should also be SHT_DWARF64. > If mixed, SHT_PROGBITS. I am not really sur...

...ovember/114125.html > > mentioned this. > > OK - thanks for clarifying. I don't really know much/enough about > linker scripts to comment on the rest of the design, and was just > confused/misunderstanding what was being suggested. For .debug_* in object files: DWARF32 -> SHT_PROGBITS (unchanged) DWARF64 -> SHT_DWARF64 or SHT_GNU_DWARF64 In LLD, we will need to allow mixed SHT_PROGBITS and SHT_DWARF64. If all input sections are SHT_DWARF64, the output section type probably should also be SHT_DWARF64. If mixed, SHT_PROGBITS. FWIW I started a generic-abi thread https://group...

...t; >> On Mon, Nov 16, 2020 at 10:42 PM Igor Kudrin <ikudrin at accesssoftek.com> > wrote: > >> > > >> > On 14.11.2020 3:42, Fāng-ruì Sòng wrote: > >> > > For .debug_* in object files: > >> > > > >> > > DWARF32 -> SHT_PROGBITS (unchanged) > >> > > DWARF64 -> SHT_DWARF64 or SHT_GNU_DWARF64 > >> > > > >> > > In LLD, we will need to allow mixed SHT_PROGBITS and SHT_DWARF64. If > >> > > all input sections are SHT_DWARF64, the output section type probably > &g...

...sections. I narrowed down the problem to the following commit and the commits around this....Please see below: commit ccba42c7eb3cdfe7824cd4b473a9688e5738fa3a Author: Andrew Ng <anng.sw at gmail.com> Date:   Tue Apr 23 12:38:52 2019 +0000     [ELF] Change default output section type to SHT_PROGBITS     This fixes an issue where a symbol only section at the start of a     PT_LOAD segment, causes incorrect alignment of the file offset for the     start of the segment which results in the output of an invalid ELF.     SHT_PROGBITS was the default output section type in the past.     Dif...

...gt;On 17.11.2020 14:05, Fāng-ruì Sòng wrote: >>On Mon, Nov 16, 2020 at 10:42 PM Igor Kudrin <ikudrin at accesssoftek.com> wrote: >>> >>>On 14.11.2020 3:42, Fāng-ruì Sòng wrote: >>>>For .debug_* in object files: >>>> >>>>DWARF32 -> SHT_PROGBITS (unchanged) >>>>DWARF64 -> SHT_DWARF64 or SHT_GNU_DWARF64 >>>> >>>>In LLD, we will need to allow mixed SHT_PROGBITS and SHT_DWARF64. If >>>>all input sections are SHT_DWARF64, the output section type probably >>>>should also be SHT_DWA...

...t; " + toString(isec) + ": " + 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 LL...

...So a YAML file will look like below. An alternative option is to introduce new top-level 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 Of...

On 17.11.2020 14:05, Fāng-ruì Sòng wrote: > On Mon, Nov 16, 2020 at 10:42 PM Igor Kudrin <ikudrin at accesssoftek.com> wrote: >> >> On 14.11.2020 3:42, Fāng-ruì Sòng wrote: >>> For .debug_* in object files: >>> >>> DWARF32 -> SHT_PROGBITS (unchanged) >>> DWARF64 -> SHT_DWARF64 or SHT_GNU_DWARF64 >>> >>> In LLD, we will need to allow mixed SHT_PROGBITS and SHT_DWARF64. If >>> all input sections are SHT_DWARF64, the output section type probably >>> should also be SHT_DWARF64. >>&g...

...gt;On 17.11.2020 14:05, Fāng-ruì Sòng wrote: >>On Mon, Nov 16, 2020 at 10:42 PM Igor Kudrin <ikudrin at accesssoftek.com> wrote: >>> >>>On 14.11.2020 3:42, Fāng-ruì Sòng wrote: >>>>For .debug_* in object files: >>>> >>>>DWARF32 -> SHT_PROGBITS (unchanged) >>>>DWARF64 -> SHT_DWARF64 or SHT_GNU_DWARF64 >>>> >>>>In LLD, we will need to allow mixed SHT_PROGBITS and SHT_DWARF64. If >>>>all input sections are SHT_DWARF64, the output section type probably >>>>should also be SHT_DWA...

Hello devs, llvm+clang doesn't emit .s/.o files which can be linked successfully, on a 64-bit compilation, with the Solaris linker ld(1). The problem lies in the way the .eh_frame section header is created. llvm+clang creates it with SHT_PROGBITS and SHT_ALLOC|SHT_WRITE, while the Solaris linker expects a SHT_AMD64_UNWIND section with SHT_ALLOC only permissions [1]. Simple example follows: root at markuse:/work/llvm/llvm/Debug+Asserts/bin# ./clang -o h hello.c -m64 ld: fatal: file /tmp/cc-LNa4VK.o: section [6].eh_frame: section type is SH...

...tions" as seen below. > ; Segment 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...

..."--gc-sections". 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/TargetLoweringObject...

Suppose i write // foo.cpp __attribute__((section(“foo”))) int x; // bar.cpp __attribute__((section(“foo”))) int y; And i compile and link these two object files together using lld. What assumptions can I make regarding alignment/padding between the two symbols? I’m comfortable getting an answer by reading the source, but that won’t tell if any properties i discover are guaranteed or just

...ovember/114125.html > > mentioned this. > > OK - thanks for clarifying. I don't really know much/enough about > linker scripts to comment on the rest of the design, and was just > confused/misunderstanding what was being suggested. For .debug_* in object files: DWARF32 -> SHT_PROGBITS (unchanged) DWARF64 -> SHT_DWARF64 or SHT_GNU_DWARF64 In LLD, we will need to allow mixed SHT_PROGBITS and SHT_DWARF64. If all input sections are SHT_DWARF64, the output section type probably should also be SHT_DWARF64. If mixed, SHT_PROGBITS. FWIW I started a generic-abi thread https://group...

...res like ELFYAML::StackSizesSection in lib/ObjectYAML/ELFYAML.h which could be simply passed around. Only tangentially relatedly, I've only just seen your previous patch/email > thread, and I do have one thing I'd like to ask if it can be changed. At > the moment, the section type is SHT_PROGBITS, but I think it would be > better, if possible, to define a new SHT_* type for the new section? In > general, it is bad design to rely on section names to distinguish between > different kinds of sections - this requires the linker and other tools to > have to do unnecessary string com...

...The first paragraph of https://sourceware.org/pipermail/binutils/2020-November/114125.html mentioned this. The section type approach is used this way (in another paragraph): <quote> If we invent a keyword (say, TYPE) to match sections by type, we could use .debug_info 0 : { *(TYPE (SHT_PROGBITS) .debug_info${RELOCATING+ .gnu.linkonce.wi.*}) } .debug_info 0 : { *(TYPE (SHT_GNU_DWARF64) .debug_info) } or .debug_info 0 : { *(TYPE (SHT_PROGBITS) .debug_info${RELOCATING+ .gnu.linkonce.wi.*} TYPE (SHT_GNU_DWARF64) .debug_info) } </quote> > > * It needs a clarificat...

Hi All, Following up on https://lists.llvm.org/pipermail/llvm-dev/2020-July/143512.html, and https://reviews.llvm.org/D85408, we would like to consider a design which allows external tools to read the structured contents of the .bb_addr_map section with library calls into an LLVM library. At the same time, we need to have tools/obj2yaml tests in place for bb_addr_map. So it sounds like the