search for: inputsections

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 meta...

I would suggest converting only part of linker generated sections to input sections to reduce amount of code changes. For example it's unlikely that SymbolTableSection or StringTableSection would ever require such treatment, so why converting them to input sections? 2016-10-19 11:03 GMT+03:00 George Rimar <grimar at accesssoftek.com>: >>This idea popped up in the review thread

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

Hi, I was doing some experiments with LLD and noticed that it pads out OutputSections with null bytes in all cases (as far as 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,

...t you have to follow. The other thing that you should do is try and work out why the VA (vma) is 6 in LD and 8 in LLD and whether this is actually a problem. The VA of the OutputSection is not guaranteed to be the same between different linkers so it may have just been that differences in order of InputSections or alignment has caused a different VA. I would check the output of the linker map file to see where it placed the Output and Input Sections to see what the answer should be. In summary: It looks like there are some Arc specific things that might need to be done. Unfortunately I don't have any...

Hi all, Working on lld aarch64 support I came across an issue where I am not sure which would be best design approach to solve. The aarch64 R_AARCH64_ABS64 relocation for PIC/PIE build requires a dynamic relocation (R_AARCH64_RELATIVE) with the value set as the addend of the relocation. For instance, when linking the crtbeginS.o which contains: Relocation section '.rela.init_array' at

...;>>> (vma) is 6 in LD and 8 in LLD and whether this is actually a problem. >>>>>> The VA of the OutputSection is not guaranteed to be the same between >>>>>> different linkers so it may have just been that differences in order >>>>>> of InputSections or alignment has caused a different VA. I would check >>>>>> the output of the linker map file to see where it placed the Output >>>>>> and Input Sections to see what the answer should be. >>>>> >>>>> LLD's getOutputSection()-&gt...

This idea popped up in the review thread for https://reviews.llvm.org/D25627 . Problem: Currently, LLD creates special sections that are not just concatenations of input sections but need link-time data generation, such as .got, .plt, interp, .mips.options, etc., as output sections. We have OutputSectionBase subclasses (e.g. GotSection, PltSection, etc.) to create data. Even though this scheme

...work out why the VA >>>> (vma) is 6 in LD and 8 in LLD and whether this is actually a problem. >>>> The VA of the OutputSection is not guaranteed to be the same between >>>> different linkers so it may have just been that differences in order >>>> of InputSections or alignment has caused a different VA. I would check >>>> the output of the linker map file to see where it placed the Output >>>> and Input Sections to see what the answer should be. >>> >>> LLD's getOutputSection()->Addr = >>> https://git...

...ORIGIN(Memory_SRAM) + LENGTH(Memory_SRAM); _HeapHigh =.; ASSERT((_HeapLow + _HEAP_SIZE < _HeapHigh), "Error: Not enough space for the heap: data section too big."); } > Memory_SRAM void OutputSection::commitSection(InputSection *isec) { if (!hasInputSections) { // If IS is the first section to be added to this section, // initialize type, entsize and flags from isec. hasInputSections = true; type = isec->type; entsize = isec->entsize; flags = isec->flags; } else { // Otherwise, check if new type or flags a...

I'm about to start working on range extension thunks in lld. This is an attempt to summarize the approach I'd like to take and what the impact will be on lld outside of thunks. I'm interested if anyone has any constraints the approach will break, alternative suggestions, or is working on something I'll need to take account of? I expect range extension thunks to be important for

> 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

Hello Rui, Thanks for the comments - Synthetic sections and rewriting relocations I think that this would definitely be worth trying. It should remove the need for thunks to be represented in the core data structures, and would allow . It would also mean that we wouldn't have to associate symbols with thunks as the relocations would directly target the thunks. ARM interworking makes reusing

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 pla...