similar to: RFC: LLD: creating linker-generated sections as input sections instead of output sections

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

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

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,

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

Hello Leslie, The errors coming from the gnu assembler are due to the file being assembled in Arm state, to get rid of the errors you'll either need to put a .thumb directive in the file, or pass -mthumb to the assembler via arm-linux-gnu-gcc -Wa,-mthumb (I think). I'm not able to explain what you are seeing in your print out as it doesn't quite match the map file. Looking at your

Hello Leslie, I don't know quite what to say as I don't know precisely what your question is? If I am not being precise enough please can you put some explicit questions in? From what I can see in the output, here are some comments. >From your arc mapfiles it looks like that in the output both linker's have given the .text output section the correct base address given the

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

Hello Leslie, I think we are going to need to know a bit more about the ELF ABI for what looks like the ArcCompact before we can help you. LLD's calculation of P (the place to be relocated) is as it is in the generic ELF specification. The Rel.Offset corresponds to the ELF r_offset field. This is covered by: "For a relocatable file, the value is the byte offset from the beginning of 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

Peter, Thanks for the great feedback! > The first is the use of a custom suffix, all other linker conventions, that I know of, use prefixes as these are much easier and faster to match against names. > This can be important in large programs compiled -ffunction-sections as there can be millions of sections to match. I understand the reason of having these conventions in linkers. On the

Hey, We would like to propose an idea that would help security harden applications that define custom sections. Motivation and Background In Chromium we have a garbage collector that implements some RTTI machinery in the form of a table. This table is used by the collector to trace and finalize garbage collected objects. We're thinking of using __attribute__((section(...))) so that the table

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

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

Are you suggesting other linker jobs such as creating _end symbols to the linker script? The linker script support was implemented after we wrote the current Writer class, so it is somewhat "plugged in" to the Writer. It might not be the best design, and not many other options have been explored. So there might be room to improve code by moving work loads from the Writer to the

Hi Andrew, Thanks for the background and context. "In your issue, just to clarify, is the ELF output from LLD also "large", or is it just the output from the llvm-objcopy operating on that ELF that is "large"? 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

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

This RFC is primarily to support the review of the range extension thunks implementation of lld. This concerns ARM and Mips as all of the thunk creation step is skipped over if the target doesn't need thunks. Mips LA25 Thunks are not range extension Thunks but these are generated using the same code, I've kept the behaviour the same as it is now, although the implementation is obviously

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

Hi Peter, On Mon, May 14, 2018 at 8:14 AM Peter Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > My understanding from the RFC is: > - All global objects in the bitcode file will be assigned a section name. > ... which is equal to the section name that they would have been emitted to if this was a regular compilation. In addition to allowing the linker to read section

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