[PATCH] D25467: [ELF] - Alternative fix to prevent possible crash on large output.

[Rui Ueyama via llvm-commits]

On Tue, Oct 18, 2016 at 8:51 AM, George Rimar <grimar at accesssoftek.com>
wrote:

> > This is a list of items that popped in my mind. Not exhaustive but
> probably good enough to start discussing what we should do next.
> >
> > - FreeBSD: what is the status of building the entire FreeBSD system with
> LLD? Can it build everything including the kernel?
> >
> > - OpenBSD: it is reported that the current LLD doesn't work well on
> their operating system.
> >
> > - Linux: pick up a distribution and build all packages with LLD to find
> out bugs and unimplemented features.
>

Well, these three items are really the most important items. :)


> >
> > - Unimplemented features: at least I wanted to support
> --no-ctors-in-init-array.
> >
>
> I reviewed gold code and found that difference in our and their
> implementation is that by default (--ctors-in-init-array)
> in gold .ctors sections are output in .init_array sections, and .dtors
> sections are output in .fini_array sections. And they preserve the
> original names (not renamed to .init_array/.fini_array) when --
> no-ctors-in-init-array specified. LLD always preserve the
> original names now. I did not notice other differences, may be I am missing
> something, what should be done here ?
>

I don't know. We might have to do nothing. I just noticed that LLD doesn't
recognize the command line option.


> > - Safe ICF: is there anything that we can do to support it? I don't like
> the way how gold support it (e.g. recognizing ctors/dtors by mangled names,
> or detecting >address-taken functions by relocations) because it seems too
> tricky to me. We might want to change LLVM to emit hints for linkers.
> >
> > - Parallelism: we haven't worked on this area intentionally because we
> are pursuing single thread performance at this moment. But because the
> linker is now fairly > mature, it might be the time to start thinking about
> it. Is there any place we can use multiple threads to speed up? The first
> thing that comes to my mind is computing > a build id using multiple
> threads.
> >
>
> As far I know MD5 and SHA1 can not be parrallized. You sure can split
> original buffer and compute multiple hashes in parrallel and combine them
> somehow at the end, but result  of hash(buf1) + hash(buf2) + .... +
> hashN(bufN) will never be equal to hash(whole bufer). Do you have some
> specific solution in mind here ?
>
> > - Ports: how much mature is PowerPC port? We want to support both BE and
> LE PowerPCs. It's also interesting to work on an open-source ISA, RISC-V,
> because the patches to support the RISC-V architecture are being merged now.
>
> ​
> And about --section-ordering-file​ option mentioned by Davide. Do we want
> to try it ? if so I probably can work on it.
> So as far I understand gold implementation this is just a file with
> wildcarded names that specifies sections order.
>

I guess it's a lower priority item.


>
>
> George.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161018/c4de4073/attachment.html>