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>
----- Original Message -----> From: "Lang Hames via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Rui Ueyama" <ruiu at google.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Bruce Hoult" <bruce at hoult.org> > Sent: Monday, March 21, 2016 5:00:02 PM > Subject: Re: [llvm-dev] Need help with code generation > > Hi All, > > > My understanding of the earlier thread is that it ended with "We > agree to disagree for now, and (potentially) revisit this later". >This was also my impression. -Hal> > 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 > > > > _______________________________________________ > 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
Rafael Espíndola via llvm-dev
2016-Mar-21 22:35 UTC
[llvm-dev] Need help with code generation
On Mar 21, 2016 6:00 PM, "Lang Hames via llvm-dev" <llvm-dev at lists.llvm.org> wrote:> > Hi All, > > My understanding of the earlier thread is that it ended with "We agree todisagree for now, and (potentially) revisit this later".> > I'm not interested in starting any new discussions at the moment, but Iwant 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? What is the use case of having the property in one but not the other? On a related note, it is the macho lld what currently prevents the asan bots from reporting failures. That would probably be a good place to start. Cheers, Rafael -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/82a64cd9/attachment.html>
Quentin Colombet via llvm-dev
2016-Mar-21 22:48 UTC
[llvm-dev] Need help with code generation
Hi Rafael,> On Mar 21, 2016, at 3:35 PM, Rafael Espíndola via llvm-dev <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. Do you have cases where this leads to actual crashes? That would be a bug, IMHO.> What is the use case of having the property in one but not the other? > >It is good to do the right thing even though the other libraries might not (yet)? ;) Cheers, Q.> On a related note, it is the macho lld what currently prevents the asan bots from reporting failures. That would probably be a good place to start. > > 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/cee26bdc/attachment.html>
Hi Rafael, Are you guys fixing llvm to also not crash on invalid input? What is the> use case of having the property in one but not the other?Slowly? Effort on handling errors is balanced with other priorities, but as a matter of policy I don't think LLVM libraries should crash on user input. On a related note, it is the macho lld what currently prevents the asan> bots from reporting failures. That would probably be a good place to start.Pete's has been working on this the last couple of days. We should have a fix soon. - Lang. On Mon, Mar 21, 2016 at 3:35 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote:> > On Mar 21, 2016 6:00 PM, "Lang Hames via llvm-dev" < > 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? What is the > use case of having the property in one but not the other? > > On a related note, it is the macho lld what currently prevents the asan > bots from reporting failures. That would probably be a good place to start. > > Cheers, > Rafael >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/7fd04ce0/attachment.html>