llvm dev - Mar 2016 - Need help with code generation

On Mon, Mar 21, 2016 at 2:46 PM, Rafael Espíndola <llvm-dev at
lists.llvm.org>
wrote:
> On 21 March 2016 at 17:34, Tim Northover via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >> My understanding is that clang and llvm themselves are designed
this way
> >> (crash when the unexpected happens).
> >
> > I don't think so. I'd view any Clang crash as a bug (probably
to be
> > prioritised below silent CodeGen and many others, but not
"working as
> > designed").
> >
> >> For example the fact that clang forks itself to be able to report
> diagnostics
> >
> > That seems like just trying to make our own job easier to me. I think
> > the entire point of the fork is to get a backtrace we can fix, and
> > point out where the user should send it.
> >
> >> llvm is full of report_fatal_error() (or worse, assertions that
can
> fire on unexpected user input).
> >
> > A bit of a grey area since LLVM isn't itself a user-facing tool,
but I
> > think I'd still say that a report_fatal_error that's not
actionable by
> > the user is actually an LLVM bug. And a segfault definitely so.
>
> It is completely trivial to crash llvm. A case I wrote today in
> another thread while waiting for tests to run:
>
> target triple = "x86_64-unknown-linux-gnu"
> @".data" = global i32 42
>
> That will crash "llc -filetype=obj". The fact that it is
considered a
> bug doesn't mean much if there is no coordinated effort to fix them.
>
I think it does, actually - that patches will be accepted to fix pretty
much any crash in LLVM. (llc isn't a user facing tool, so that's a
praticularly low priority - but as a general library (I assume your example
also crashes Clang, which would be where this would surface in a more
important way) it's pretty well accepted that crashes are bugs, I think)

> Right now lld is already harder to crash than llvm. We are just being
> honest about the fact that it is possible to craft a .o file that will
> crash it.
>
But the difference seems to be you know about these cases and don't
consider them to be bugs/anything to fix. In LLVM if they're known,
they're
at least considered bugs and often/usually considered by someone to be
worth fixing at some point.

- Dave

>
> Cheers,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/09347234/attachment.html>

On Mon, Mar 21, 2016 at 10:49 PM, David Blaikie via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> On Mon, Mar 21, 2016 at 2:46 PM, Rafael Espíndola <llvm-dev at
lists.llvm.org
> > wrote:
>
>> On 21 March 2016 at 17:34, Tim Northover via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> >> My understanding is that clang and llvm themselves are
designed this
>> way
>> >> (crash when the unexpected happens).
>> >
>> > I don't think so. I'd view any Clang crash as a bug
(probably to be
>> > prioritised below silent CodeGen and many others, but not
"working as
>> > designed").
>> >
>> >> For example the fact that clang forks itself to be able to
report
>> diagnostics
>> >
>> > That seems like just trying to make our own job easier to me. I
think
>> > the entire point of the fork is to get a backtrace we can fix, and
>> > point out where the user should send it.
>> >
>> >> llvm is full of report_fatal_error() (or worse, assertions
that can
>> fire on unexpected user input).
>> >
>> > A bit of a grey area since LLVM isn't itself a user-facing
tool, but I
>> > think I'd still say that a report_fatal_error that's not
actionable by
>> > the user is actually an LLVM bug. And a segfault definitely so.
>>
>> It is completely trivial to crash llvm. A case I wrote today in
>> another thread while waiting for tests to run:
>>
>> target triple = "x86_64-unknown-linux-gnu"
>> @".data" = global i32 42
>>
>> That will crash "llc -filetype=obj". The fact that it is
considered a
>> bug doesn't mean much if there is no coordinated effort to fix
them.
>>
>
> I think it does, actually - that patches will be accepted to fix pretty
> much any crash in LLVM. (llc isn't a user facing tool, so that's a
> praticularly low priority - but as a general library (I assume your example
> also crashes Clang, which would be where this would surface in a more
> important way) it's pretty well accepted that crashes are bugs, I
think)
>
>
>> Right now lld is already harder to crash than llvm. We are just being
>> honest about the fact that it is possible to craft a .o file that will
>> crash it.
>>
>
> But the difference seems to be you know about these cases and don't
> consider them to be bugs/anything to fix. In LLVM if they're known,
they're
> at least considered bugs and often/usually considered by someone to be
> worth fixing at some point.
>
I think this is the same from the user's point of view. If LLVM is not
crash-bug-free in the version you are using, you need some precaution such
as forking in order to protect your program from crashing if you need 100%
guarantee.

> - 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/826ff3fa/attachment.html>

>> Right now lld is already harder to crash than llvm. We are just being
>> honest about the fact that it is possible to craft a .o file that will
>> crash it.
>
>
> But the difference seems to be you know about these cases and don't
consider
> them to be bugs/anything to fix. In LLVM if they're known, they're
at least
> considered bugs and often/usually considered by someone to be worth fixing
> at some point.
>From the user seeing a crash, what is the difference? lld will crash
less often than llvm.

If someone really cares (I don't), they can write a patch. Such a
patch would be evaluated on its cost and benefits. Given that its
benefits are close to nothing (don't crash when someone is playing
with hexedit?), the cost would have to be *really* low. Also, we are
not even in a position to evaluate the cost right now, since we still
have actual features to implement.

Cheers,
Rafael

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.

- Lang.

On Mon, Mar 21, 2016 at 2:54 PM, Rui Ueyama via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Mon, Mar 21, 2016 at 10:49 PM, David Blaikie via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>>
>> On Mon, Mar 21, 2016 at 2:46 PM, Rafael Espíndola <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> On 21 March 2016 at 17:34, Tim Northover via llvm-dev
>>> <llvm-dev at lists.llvm.org> wrote:
>>> >> My understanding is that clang and llvm themselves are
designed this
>>> way
>>> >> (crash when the unexpected happens).
>>> >
>>> > I don't think so. I'd view any Clang crash as a bug
(probably to be
>>> > prioritised below silent CodeGen and many others, but not
"working as
>>> > designed").
>>> >
>>> >> For example the fact that clang forks itself to be able to
report
>>> diagnostics
>>> >
>>> > That seems like just trying to make our own job easier to me.
I think
>>> > the entire point of the fork is to get a backtrace we can fix,
and
>>> > point out where the user should send it.
>>> >
>>> >> llvm is full of report_fatal_error() (or worse, assertions
that can
>>> fire on unexpected user input).
>>> >
>>> > A bit of a grey area since LLVM isn't itself a user-facing
tool, but I
>>> > think I'd still say that a report_fatal_error that's
not actionable by
>>> > the user is actually an LLVM bug. And a segfault definitely
so.
>>>
>>> It is completely trivial to crash llvm. A case I wrote today in
>>> another thread while waiting for tests to run:
>>>
>>> target triple = "x86_64-unknown-linux-gnu"
>>> @".data" = global i32 42
>>>
>>> That will crash "llc -filetype=obj". The fact that it is
considered a
>>> bug doesn't mean much if there is no coordinated effort to fix
them.
>>>
>>
>> I think it does, actually - that patches will be accepted to fix pretty
>> much any crash in LLVM. (llc isn't a user facing tool, so
that's a
>> praticularly low priority - but as a general library (I assume your
example
>> also crashes Clang, which would be where this would surface in a more
>> important way) it's pretty well accepted that crashes are bugs, I
think)
>>
>>
>>> Right now lld is already harder to crash than llvm. We are just
being
>>> honest about the fact that it is possible to craft a .o file that
will
>>> crash it.
>>>
>>
>> But the difference seems to be you know about these cases and don't
>> consider them to be bugs/anything to fix. In LLVM if they're known,
they're
>> at least considered bugs and often/usually considered by someone to be
>> worth fixing at some point.
>>
>
> I think this is the same from the user's point of view. If LLVM is not
> crash-bug-free in the version you are using, you need some precaution such
> as forking in order to protect your program from crashing if you need 100%
> guarantee.
>
>
>> - 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/73c00431/attachment.html>

On Mon, Mar 21, 2016 at 2:54 PM, Rui Ueyama <ruiu at google.com> wrote:
> On Mon, Mar 21, 2016 at 10:49 PM, David Blaikie via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>>
>> On Mon, Mar 21, 2016 at 2:46 PM, Rafael Espíndola <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> On 21 March 2016 at 17:34, Tim Northover via llvm-dev
>>> <llvm-dev at lists.llvm.org> wrote:
>>> >> My understanding is that clang and llvm themselves are
designed this
>>> way
>>> >> (crash when the unexpected happens).
>>> >
>>> > I don't think so. I'd view any Clang crash as a bug
(probably to be
>>> > prioritised below silent CodeGen and many others, but not
"working as
>>> > designed").
>>> >
>>> >> For example the fact that clang forks itself to be able to
report
>>> diagnostics
>>> >
>>> > That seems like just trying to make our own job easier to me.
I think
>>> > the entire point of the fork is to get a backtrace we can fix,
and
>>> > point out where the user should send it.
>>> >
>>> >> llvm is full of report_fatal_error() (or worse, assertions
that can
>>> fire on unexpected user input).
>>> >
>>> > A bit of a grey area since LLVM isn't itself a user-facing
tool, but I
>>> > think I'd still say that a report_fatal_error that's
not actionable by
>>> > the user is actually an LLVM bug. And a segfault definitely
so.
>>>
>>> It is completely trivial to crash llvm. A case I wrote today in
>>> another thread while waiting for tests to run:
>>>
>>> target triple = "x86_64-unknown-linux-gnu"
>>> @".data" = global i32 42
>>>
>>> That will crash "llc -filetype=obj". The fact that it is
considered a
>>> bug doesn't mean much if there is no coordinated effort to fix
them.
>>>
>>
>> I think it does, actually - that patches will be accepted to fix pretty
>> much any crash in LLVM. (llc isn't a user facing tool, so
that's a
>> praticularly low priority - but as a general library (I assume your
example
>> also crashes Clang, which would be where this would surface in a more
>> important way) it's pretty well accepted that crashes are bugs, I
think)
>>
>>
>>> Right now lld is already harder to crash than llvm. We are just
being
>>> honest about the fact that it is possible to craft a .o file that
will
>>> crash it.
>>>
>>
>> But the difference seems to be you know about these cases and don't
>> consider them to be bugs/anything to fix. In LLVM if they're known,
they're
>> at least considered bugs and often/usually considered by someone to be
>> worth fixing at some point.
>>
>
> I think this is the same from the user's point of view. If LLVM is not
> crash-bug-free in the version you are using, you need some precaution such
> as forking in order to protect your program from crashing if you need 100%
> guarantee.
>
Crashes seem very different from a user's point of view - does the program
execute undefined behavior (potentially silently producing output and
exiting 0) or does it have well defined behavior (even if that behavior is
"print an error and exit(1)").

>
>
>> - 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/e4ffa27b/attachment.html>

On Mon, Mar 21, 2016 at 2:55 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:
> >> Right now lld is already harder to crash than llvm. We are just
being
> >> honest about the fact that it is possible to craft a .o file that
will
> >> crash it.
> >
> >
> > But the difference seems to be you know about these cases and
don't
> consider
> > them to be bugs/anything to fix. In LLVM if they're known,
they're at
> least
> > considered bugs and often/usually considered by someone to be worth
> fixing
> > at some point.
>
> From the user seeing a crash, what is the difference? lld will crash
> less often than llvm.
>
> If someone really cares (I don't), they can write a patch. Such a
> patch would be evaluated on its cost and benefits. Given that its
> benefits are close to nothing (don't crash when someone is playing
> with hexedit?), the cost would have to be *really* low.

That seems like the difference - if we consider any crash a bug by
definition then the bar is low to fix a crasher, no matter the obscurity of
the input.

> Also, we are
> not even in a position to evaluate the cost right now, since we still
> have actual features to implement.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/13e15ac6/attachment.html>

On Mar 21, 2016 5:49 PM, "David Blaikie" <dblaikie at gmail.com>
wrote:
>
>
>
> On Mon, Mar 21, 2016 at 2:46 PM, Rafael Espíndola <llvm-dev at
lists.llvm.org>
wrote:
>>
>> On 21 March 2016 at 17:34, Tim Northover via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> >> My understanding is that clang and llvm themselves are
designed this
way
>> >> (crash when the unexpected happens).
>> >
>> > I don't think so. I'd view any Clang crash as a bug
(probably to be
>> > prioritised below silent CodeGen and many others, but not
"working as
>> > designed").
>> >
>> >> For example the fact that clang forks itself to be able to
report
diagnostics
>> >
>> > That seems like just trying to make our own job easier to me. I
think
>> > the entire point of the fork is to get a backtrace we can fix, and
>> > point out where the user should send it.
>> >
>> >> llvm is full of report_fatal_error() (or worse, assertions
that can
fire on unexpected user input).
>> >
>> > A bit of a grey area since LLVM isn't itself a user-facing
tool, but I
>> > think I'd still say that a report_fatal_error that's not
actionable by
>> > the user is actually an LLVM bug. And a segfault definitely so.
>>
>> It is completely trivial to crash llvm. A case I wrote today in
>> another thread while waiting for tests to run:
>>
>> target triple = "x86_64-unknown-linux-gnu"
>> @".data" = global i32 42
>>
>> That will crash "llc -filetype=obj". The fact that it is
considered a
>> bug doesn't mean much if there is no coordinated effort to fix
them.
>
>
> I think it does, actually - that patches will be accepted to fix pretty
much any crash in LLVM. (llc isn't a user facing tool, so that's a
praticularly low priority -

I am pretty sure clang crashes if you translate the above example to C.

Philosophical question: what is the difference of a non bug and a bug of
such low priority that it is never fixed?

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

On Mon, Mar 21, 2016 at 4:35 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:
>
> On Mar 21, 2016 5:49 PM, "David Blaikie" <dblaikie at
gmail.com> wrote:
> >
> >
> >
> > On Mon, Mar 21, 2016 at 2:46 PM, Rafael Espíndola <
> llvm-dev at lists.llvm.org> wrote:
> >>
> >> On 21 March 2016 at 17:34, Tim Northover via llvm-dev
> >> <llvm-dev at lists.llvm.org> wrote:
> >> >> My understanding is that clang and llvm themselves are
designed this
> way
> >> >> (crash when the unexpected happens).
> >> >
> >> > I don't think so. I'd view any Clang crash as a bug
(probably to be
> >> > prioritised below silent CodeGen and many others, but not
"working as
> >> > designed").
> >> >
> >> >> For example the fact that clang forks itself to be able
to report
> diagnostics
> >> >
> >> > That seems like just trying to make our own job easier to me.
I think
> >> > the entire point of the fork is to get a backtrace we can
fix, and
> >> > point out where the user should send it.
> >> >
> >> >> llvm is full of report_fatal_error() (or worse,
assertions that can
> fire on unexpected user input).
> >> >
> >> > A bit of a grey area since LLVM isn't itself a
user-facing tool, but I
> >> > think I'd still say that a report_fatal_error that's
not actionable by
> >> > the user is actually an LLVM bug. And a segfault definitely
so.
> >>
> >> It is completely trivial to crash llvm. A case I wrote today in
> >> another thread while waiting for tests to run:
> >>
> >> target triple = "x86_64-unknown-linux-gnu"
> >> @".data" = global i32 42
> >>
> >> That will crash "llc -filetype=obj". The fact that it is
considered a
> >> bug doesn't mean much if there is no coordinated effort to fix
them.
> >
> >
> > I think it does, actually - that patches will be accepted to fix
pretty
> much any crash in LLVM. (llc isn't a user facing tool, so that's a
> praticularly low priority -
>
> I am pretty sure clang crashes if you translate the above example to C.
>
> Philosophical question: what is the difference of a non bug and a bug of
> such low priority that it is never fixed?
>
 One where contributors are encouraged to provide patches to fix things,
versus one where contributors are told that there is a high bar to get such
a patch contributed seems like a pretty big difference to me.

It changes who's willing to contribute to the project, or build tools based
on it.

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/261f519a/attachment.html>