search for: outputsections

...w 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 sections. >> >>This approach would solve the problems described above. Now that we crea...

...es the > amount of opportunities for both implementers and users to make > mistakes, and it makes some implementation details more complicated. > Where we would have been able to guarantee a single OutputSection, we > may have many clumps of InputSections distributed across several > OutputSections. In some cases it is user error to split InputSections > apart as they need to be contiguous, which requites diagnostics, and > in some cases algorithms need to be careful, for example in embedded > systems it is not always appropriate to string merge between > OutputSections as these O...

...nker 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 sections. This approach would solve the problems described above. Now that we create .got as an special input section wi...

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

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

On Tue, Feb 28, 2017 at 12:10 PM, Rui Ueyama <ruiu at google.com> wrote: > I don't think getVA is particularly expensive, and if it is not expensive > I wouldn't cache its result. Did you experiment to cache getVA results? I > think you can do that fairly easily by adding a std::atomic_uint64_t to > SymbolBody and use it as a cache for getVA. > You're right,

...pt->processNonSectionCommands() // This should only be done once Correct. > In theory all the other __start and __end symbols could still be kept > separate if the linker script commands were created late, and in a > compatible way. I also don't think that this means removing > OutputSections::Sections just yet either? Probably not, but it might got away in the future. > I don't think that we are proposing to follow the ld.bfd model of > driving the default case via a built in linker script yet? I think > that this would be considerably more work than just this limited &g...

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

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

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

On Tue, Feb 28, 2017 at 11:39 PM, Rui Ueyama <ruiu at google.com> wrote: > I also did a quick profiling a few months ago and noticed just like you > that scanRelocations consumes a fairly large percentage of overall > execution time. That caught my attention because at the time I was looking > for a place that I can parallelize. > > scanRelocations is not parallelizable

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

...d if the output section is > different. > Correct. Plus, others can be enabled if they're safe to apply when we know things are going to the same output section. > The common use cases that I can see that might not fit perfectly into > that model: > - Code that is in different OutputSections but it will be logically > correct and in many cases desirable to perform transformations on as > if they were in the same output section. Right. The output section that the linker communicates for a symbol doesn't need to correspond to a "physical" output section. So let'...

...#include "llvm/Support/FileOutputBuffer.h" #include "llvm/Support/raw_ostream.h" #include <climits> +#include <unordered_set> using namespace llvm; using namespace llvm::ELF; @@ -922,6 +924,157 @@ static void sortBySymbolsOrder(ArrayRef<OutputSection *> OutputSections) { Sec->sort([&](InputSectionBase *S) { return SectionOrder.lookup(S); }); } +// Sort sections by the profile data provided in the .note.llvm.callgraph +// sections. +// +// This algorithm is based on Call-Chain Clustering from: +// Optimizing Function Placement for Large-Scale Dat...

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