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

[Davide Italiano via llvm-commits]

On Tue, Oct 18, 2016 at 12:36 PM, Rui Ueyama via llvm-commits
<llvm-commits at lists.llvm.org> wrote:
> 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.
>

I am under the impression that the notion of priority largely depends
on somebody's point of view. For my purposes, lld feature-wise is
quite ready (modulo dwo and gdb-index which are getting implemented
anyway), and I have a compelling use-case for the Pettis-Hansen
profiling (at least, something I would like to give it a try), so this
is near the top of my list. You can of course disagree, but saying
it's lower priority is bit of a stretch.

Thanks,

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare