[llvm-dev] Need help with code generation

Tue Mar 22 13:04:34 PDT 2016

On Tue, Mar 22, 2016 at 12:04 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
> > From: "Lang Hames via llvm-dev" <llvm-dev at lists.llvm.org>
> > To: "David Blaikie" <dblaikie at gmail.com>
> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Bruce Hoult" <bruce at hoult.org
> >
> > Sent: Tuesday, March 22, 2016 1:57:10 PM
> > Subject: Re: [llvm-dev] Need help with code generation
> >
> >
> >
> > Hi Rafael,
> >
> >
> >
> > It is really annoying how much people care about "security" to
> > criticize my work,
> >
> >
> > FWIW it was never my intention to criticize your work. I think your
> > work is amazing, and I hope you continue. What I've taken issue with
> > is the policy stance. I think LLVM projects should aim for
> > robustness even knowing they're going to fall short, because I think
> > there is a real difference between a project which can be easily
> > exploited, and one that takes effort to exploit.
> >
>
>  +1
>

Agreed - it's great that a linker is being produced that's fast and
carefully implemented, etc.

There just seems to be some disagreement about what the best tradeoffs are.

>
> >
> > Would it end this thread if I went that way? Just say that there are
> >
> >
> >
> > bugs in lld and just not fix them for over a year?
> >
> >
> > It would make a big difference if it was "Yes, these are bugs but not
> > high priority for the current/active contributors to invest time in
> > fixing (but happy to review patches to fix them, etc)" versus "these
> > are not bugs/it's highly unlikely we'd accept patches to fix them".
> >
> >
> > +1
>
> +1
>
>  -Hal
>
> >
> >
> > Cheers,
> > Lang.
> >
> >
> >
> >
> > On Tue, Mar 22, 2016 at 11:54 AM, David Blaikie via llvm-dev <
> > llvm-dev at lists.llvm.org > wrote:
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Mar 22, 2016 at 11:43 AM, Rafael Espíndola <
> > llvm-dev at lists.llvm.org > wrote:
> >
> >
> > >
> > > This is a completely inappropriate comparison. LibreSSL is a
> > > cryptographic library. Creating a high-quality cryptographic
> > > library requires much more than eliminating buffer overruns
> > > (etc.).
> >
> > What I don't get this what is the point of a "somewhat secure". Does
> > it make a difference if takes 5 minutes of 5 hours to find a buffer
> > overflow?
> >
> > >> What allocator would you start with?
> > >>
> > >
> > > We recently had a bunch of patches fixing issues found when fuzz
> > > testing LLVM with ASAN, and I thought that was a very positive
> > > development.
> > >
> >
> > And today it is still way easier to crash llvm than lld. I posted two
> > crashes with just what I noticed going on the list. No one even
> > posted an ELF that would crash lld.
> >
> >
> >
> > No, we were responding to the stated policy that it's intentional
> > that LLD would crash/UB on certain inputs. We're debating that
> > policy/intention.
> >
> >
> > It is really annoying how much people care about "security" to
> > criticize my work, but never enough to send a patch. llvm.org/pr21466
> > is open since Nov 2014. That is on the side of the project that
> > should
> > be handling broken files.
> >
> >
> > Would it end this thread if I went that way? Just say that there are
> > bugs in lld and just not fix them for over a year?
> >
> >
> >
> > It would make a big difference if it was "Yes, these are bugs but not
> > high priority for the current/active contributors to invest time in
> > fixing (but happy to review patches to fix them, etc)" versus "these
> > are not bugs/it's highly unlikely we'd accept patches to fix them".
> >
> > Across the project we certainly prioritize bugs based on impact to
> > those who are involved - we tend to fix Clang crash-on-valid faster
> > than crash-on-invalid (certainly Kostya's been frustrated by lack of
> > traction on some of the fuzzer findings - because few people need a
> > security hardened LLVM/Clang, but generally "doesn't crash" is
> > considered to be a valid/accepted goal, even if it's not hardened).
> > Some bugs impact some users more than others, so are more important
> > to some developers. 'tis the way of things.
> >
> > - Dave
> >
> >
> >
> >
> >
> > Cheers,
> > Rafael
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160322/510b64b0/attachment.html>