[llvm-dev] [LLVM-DEV][LLD] RFC Range Thunks Implementation review for ARM and Mips

Rui Ueyama via llvm-dev llvm-dev at lists.llvm.org
Wed Apr 5 16:24:55 PDT 2017

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
LinkerScript. But we need to careful not to hurt performance by doing that.

On Wed, Apr 5, 2017 at 4:14 PM, Rafael EspĂ­ndola via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> > Proposed implementation for range extension thunks
> > At a high-level we need to solve the following problems:
> > - Assign addresses more than once
> > - Maintain state between successive calls of createThunks()
> > - Synchronization of the linker script and the OutputSection after
> adding thunks
> This last past seems to be the messier. The issue is not with the
> patch, is with the existing infrastructure that uses a completely
> different representation for linker scripts and non linker scripts.
> What I think is needed is for the writer to create a dummy "script"
> and use what is now LinkerScript::assignAddresses. That "script" would
> * Contain only OutputSectionCommand.
> * All string manipulations would have been moved before assignAddress.
> * All the orphan handling would have been made explicit before
> assignAddress.
> * Each OutputSectionCommand would contain just a InputSectionDescription.
> With this the thunk creation should be able to add thunk to a single
> location.
> Cheers,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170405/9a9ccad9/attachment.html>

More information about the llvm-dev mailing list