llvm dev - Mar 2016 - Need help with code generation

> On Mar 21, 2016, at 4:37 PM, Rafael Espíndola <rafael.espindola at
gmail.com> wrote:
> 
> 
> On Mar 21, 2016 6:48 PM, "Quentin Colombet" <qcolombet at
apple.com <mailto:qcolombet at apple.com>> wrote:
> >
> > Hi Rafael,
> >
> >> On Mar 21, 2016, at 3:35 PM, Rafael Espíndola via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
> >>
> >>
> >> On Mar 21, 2016 6:00 PM, "Lang Hames via llvm-dev"
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
> >> >
> >> > Hi All,
> >> >
> >> > My understanding of the earlier thread is that it ended with
"We agree to disagree for now, and (potentially) revisit this later".
> >> >
> >> > I'm not interested in starting any new discussions at the
moment, but I want to make sure we avoid the echo chamber effect too, so: The
position of the mach-o tool developers is that crashing on malformed input
should be considered a bug, and to that end we're working to improve our
error detection and reporting.
> >>
> >> Are you guys fixing llvm to also not crash on invalid input?
> >
> >
> > I believe the IR verifier already complains on such cases.
> >
> 
> Not even close. Not the example in my other email.
> 
> 
Great example!
I believe users generating this kind of IR would prefer an error on why the code
is invalid to realize what they missed in their “frontend”.

Could you file a PR?

Thanks,
-Quentin
> Cheers,
> Rafael
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/8d8e4a6c/attachment.html>

:
>>
>
> Great example!
> I believe users generating this kind of IR would prefer an error on why
the code is invalid to realize what they missed in their
“frontend”.
>
> Could you file a PR?
The example is already from another thread. The point is that it is an
example. Look at most variable length allocations in llvm and you should be
able to write another crasher.

Cheers,
Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/3398d780/attachment.html>

Hi Rui,

In such a hostile environment, do you really run any linker in
an
> unprotected environment?

Not that I know of, but it's not an unreasonable thing to want to do: Run a
linker on 3rd party input and have it link (or error out), not execute
arbitrary code.

Before it comes up yet again - I'm know that it is practically impossible
to be fully bug-free, but that goes for any software project, and other
software projects don't use it as an excuse not to try at all. LLVM's
policy should be to try to detect errors in user input and exit cleanly.
Exactly how we prioritize work on that is a challenge, but again - it's a
challenge on any project.

Cheers,
Lang.

On Mon, Mar 21, 2016 at 5:17 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:
> :
> >>
> >
> > Great example!
> > I believe users generating this kind of IR would prefer an error on
why
> the code is invalid to realize what they missed in their “frontend”.
> >
> > Could you file a PR?
>
> The example is already from another thread. The point is that it is an
> example. Look at most variable length allocations in llvm and you should be
> able to write another crasher.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/38033334/attachment.html>