search for: inputsection

I've been working on supporting ARM/Thumb interworking thunks in LLD and have encountered a limitation that I think it is worth bringing up in a wider context. This is all LLD specific, apologies if I've abused llvm-dev here. TL;DR summary: - Thunks in lld may not work if they are added to InputSections that have already been scanned. - There is a short term fix, but in the longer term I think that we will want to allow multiple passes of the relocations. - I'd like to know if there are any preferences on a solution. The current thunk implementation scans for and adds Thunks to InputSections...

On Wed, Oct 19, 2016 at 3:34 AM, Peter Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Thanks for the RFC. > > I'm in favour of the option of creating InputSections for some linker > generated content. I think it would add extra flexibility to the > linker. ARM's proprietary linker uses the equivalent of InputSections > with a pseudo linker defined ObjectFile for SHF_ALLOC content. As > Eugene points out it isn't always appropriate for met...

...section. There's no clean way to handle this >> linker script. >> >>Proposal: >> >>Here's my idea: how about creating all special sections as input sections >> instead of output sections? >> >>GotSection, PltSection, etc. will be subclasses of InputSection that don't >> have corresponding input files. What they will do remain the same. They will >> be added to >OutputSections just like other regular sections are added. I >> think we could simplify OutputSection a lot -- OutputSection will probably >> become a dumb conta...

Hi, MIPS LA25 thunk is used to call PIC function from non-PIC code. Usually it contains three instructions: lui $25, %hi(func) addiu $25, $25, %lo(func) j func We can write such thunk in an arbitrary place of the generated file. But if a PIC function requires the thunk is the first routine in a section, we can optimize the code and escape jump instruction. To do so we just write the

...I could tell). However, for executable sections on some targets, 0x00 forms part of an executable instruction that is not nop. In particular, for x86_64 targets at least, the sequence 0x00 0x00 is an add instruction. This can result in confusing disassembly. For example, on x86_64, given a simple InputSection that is a single "0xc3 retq" instruction, and given an alignment of 16 bytes, 15 null bytes are inserted between the end of that InputSection and the next. In the disassembly I then see the retq instruction followed by a series of adds, the last of which actually consumes 1 or more bytes...

...le file, the value is the byte offset from the beginning of the section to the storage unit affected by the relocation." For LLD we are calculating the virtual address (VA) of P, as I understand it this is equivalent to the vma used in BFD. Assuming that the relocation is relocating a regular InputSection from the basic-arc.o object then the LLD calculation of P = getOutputSection()->Addr + getOffset(Rel.Offset); translates to: (VA of OutputSection) + (Offset of InputSection within OutputSection) + (Offset within InputSection given by r_offset) The BFD linker seems to be doing the equivalent cal...

...xt segment (in this case frame_dummy). I am trying to made this on lld, but current step sequence is: - Write::run \_ Write::createSections \_ Write::scanRelocs \_ Write::addReloc // Dynamic Relocation creation \_ Write::writeSections \_ OutputSectionBase::writeTo \_ InputSection::writeTo \_ InputSection::relocate \_ TargetInfo::relocateOne The problem is only at TargetInfo::relocate the target (aarch64) will see that the relocation is a R_AARCH64_ABS64 one and thus will need to create a dynamic R_AARCH64_RELATIVE relocation. Also from comments a...

...ARC_COMPACT2)) { + uint64_t M = 0; + if (Type == R_ARC_32_PCREL || Type == R_ARC_PC32 || + Type == R_ARC_GOTPC32 || Type == R_ARC_GOTPC) + M = 4; // bitsize >= 32 ? 4 : 0 + AddrLoc = (getOutputSection()->Addr /* output_section->vma */ + + cast<InputSection>(this)->OutSecOff /* output_offset */ + + Offset /* reloc_offset */ - M) & ~0x3; + } uint64_t TargetVA = SignExtend64( getRelocTargetVA(Type, Rel.Addend, AddrLoc, *Rel.Sym, Expr), Bits); Looking at your calculation for AddrLoc, it seems like your calculation...

...ction is an output section, so it cannot be added to other output section. There's no clean way to handle this linker script. Proposal: Here's my idea: how about creating all special sections as input sections instead of output sections? GotSection, PltSection, etc. will be subclasses of InputSection that don't have corresponding input files. What they will do remain the same. They will be added to OutputSections just like other regular sections are added. I think we could simplify OutputSection a lot -- OutputSection will probably become a dumb container that just concatenates all input se...

...s not 0 modulo OutputSection alignment. >From the map file we can see that lld is aligning the OutputSection to the nearest 4-byte boundary, GNU-ld is placing the OutputSection on the requested address, but is adding padding before the .text section to make sure that in the final executable the InputSection is aligned. LLD Address Size Align Out In Symbol 00011008 00000018 4 .text 00011008 00000018 4 arm-thumb-undefined-weak.o:(.text) 00011008 00000000 0 $t.0 00011008 00000000 0 _start LD .text 0x0000000000011006 0...

...;? Do you have a simple sample to demonstrate this issue?" The ELF size is actually smaller, compared to what was generated from LLVM 7.x. (~900Kb vs ~250Kb) When we run llvm-objcopy -O Binary blah.elf blah.bin, it would generate a 400Mb binary file. I presume the `noload` flag used in `InputSection` is not properly enforced throughout the code. CommitSection is not applied to .heap and .stack section as I can recall during my debug.... .stack (NOLOAD) :ALIGN(4) { _StackLow =.; . +=_STACK_SIZE; /* Multiple of 4, asserted above. */ _StackHigh =.;...

...nterworking and Mips PIC to non-PIC calls): - A Regular, Shared or Undefined symbol may have a single thunk - For each relocation to a symbol S, if we need a thunk we use the thunk for S as the target of the relocation rather than S. The thunk will transfer control to S. - Thunks are assigned to an InputSection, these are written out when the InputSection is written. The InputSection with the Thunk contains either the caller (ARM) or callee (Mips). - For all existing thunks, the decision of whether a thunk is needed is not dependent on address. A Thumb branch to ARM will always need a thunk, no matter the...

> Is anyone already working on it? If not then I can take this task. Me - not. George.

We have fairly large and complex code to handle relocations in Writer.cpp, Target.cpp, OutputSections.cpp and InputSections.cpp. They started with simple code, but because each patch added a small piece of code to the existing one, it is becoming out of control now. For example, we have lots of entangled boolean flags in the functions that interfere with each other in an obscure fashion. Even I don't understand all...

...rking thunks in LLD >> and have encountered a limitation that I think it is worth bringing up >> in a wider context. This is all LLD specific, apologies if I've abused >> llvm-dev here. >> >> TL;DR summary: >> - Thunks in lld may not work if they are added to InputSections that >> have already been scanned. >> - There is a short term fix, but in the longer term I think that we >> will want to allow multiple passes of the relocations. >> - I'd like to know if there are any preferences on a solution. -- Simon Atanasyan

...gt;> - A Regular, Shared or Undefined symbol may have a single thunk >> - For each relocation to a symbol S, if we need a thunk we use the >> thunk for S as the target of the relocation rather than S. The thunk >> will transfer control to S. >> - Thunks are assigned to an InputSection, these are written out when >> the InputSection is written. The InputSection with the Thunk contains >> either the caller (ARM) or callee (Mips). >> - For all existing thunks, the decision of whether a thunk is needed >> is not dependent on address. A Thumb branch to ARM wil...

On 2020-11-18, Teresa Johnson via llvm-dev wrote: >AFAIK this effort stalled when Tobias changed jobs. Adding Sergei who may >know the current status of the support within Qualcomm. > >Teresa > >On Wed, Nov 18, 2020 at 11:12 AM Mitra, Gaurav via llvm-dev < >llvm-dev at lists.llvm.org> wrote: > >> Hello All, >> >> >> >> I’d like to pick up

>Thank you for taking a look. I think that the answer depends on how much slower GNU linkers are with separate .eh_frame sections. If it is not too slow, it may make >sense to generate split .eh_frame sections unconditionally. Otherwise, we might want to add a new option so that clang doesn't produce split .eh_frame sections by >default. I'll start investigating the

Hi Rafael, On 07/31/2017 04:20 PM, Rafael Avila de Espindola via llvm-dev wrote: > However, do we need to start with instrumentation? The original paper > uses sampling with good results and current intel cpus can record every > branch in a program. > > I would propose starting with just an lld patch that reads the call > graph from a file. The format would be very similar to

...n shortened from 18 bytes to 12 bytes due to the other changes. On Tue, Jul 11, 2017 at 1:59 PM, Peter Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello, > > To the best of my knowledge I think the closest analogue is something > like the Synthetic EHFrame and MergeInputSections, not strictly code > relaxation, but these do involve changes in size of sections. > > Can I ask you a quick question? In many architectures not all > pc-relative offsets are exposed to the linker as relocations so it > isn't safe to change the sizes of sections in arbitrary pl...