[PATCH] [lld] Make ELFLinkingContext own LinkerScript buffers

[Rafael Auler]

I also want to solve the problem of this patch (make ELFLinkingContext own
the buffers) without mixing with future directions on cooking linkerscript
AST. However, we will essentially end up with a vector of BumpPtrAllocators
in ELFLinkingContext (one for each linker script), which makes the code, in
my opinion, much harder to understand (it's better to have "hey, these are
a bunch of linkerscripts" than "hey, here are a bunch of unnamed buffers
that need to be anchored somewhere"). What are the benefits of this? We
avoid including LinkerScript.h into ELFLinkingContext.h, but that is
something that we will eventually need to do to avoid rewriting all classes
in LinkerScript.h in their "cooked" version, don't you think?

For example, if you look specifically at the problem of mapping input
sections to output sections, we already have classes that encode this same
information in the script namespace (script::OutputSectionDescription in
the raw script AST) and in SectionChunks.h (template class
lld::OutputSection<>), used by DefaultLayout. I wanted to avoid creating
yet another class such as "CookedOutputSectionInfo", and that's why I had
an intent on preserving the original linker script AST structure in the
LinkingContext -- mostly to avoid rewriting the same info in different data
structures that stores the same information that is already exposed in the
AST.

Let me know your thoughts and thanks for reviewing this.

On Sun, Feb 1, 2015 at 9:01 PM, Rui Ueyama <ruiu at google.com> wrote:

> I didn't think hard enough about that, but it might be good to have a
> class to cook linker scripts. But if you have such class, you can
> instantiate that class in the driver and only set that class instance to
> the linking context, no? You wouldn't have to add a pointer to linker
> script ASTs to the linking context, I guess.
>
> I prefer a patch that does one thing; in this case, we should try to fix
> the unsafe memory access first, so I'd fix that without adding any new
> feature.
>
>
> http://reviews.llvm.org/D7323
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150201/77b83b5e/attachment.html>