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

[Rui Ueyama via llvm-commits]

On Tue, Oct 18, 2016 at 8:47 PM, Davide Italiano <davide at freebsd.org> wrote:

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

Apologies for my wording. I should have clearly said that that's just my
opinion. I'm happy to help you if you decide to work on this item.


> Thanks,
>
> --
> Davide
>
> "There are no solved problems; there are only problems that are more
> or less solved" -- Henri Poincare
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161018/44d02641/attachment.html>