[lldb-dev] Interest in enabling -Werror by default
Hi, It seems that enabling -Werror by default is within reach for lldb now. There currently are three warnings that remain with gcc 5.1 on Linux, and the build is clean of warnings with clang. There are two instances of type range limitations on comparisons in asserts, and one instance of string formatting which has a GNU incompatibility. Is there any interest in enabling -Werror by default to help keep the build clean going forward? -- Saleem Abdulrasool compnerd (at) compnerd (dot) org ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Interest in enabling -Werror by default
On Tuesday, February 16, 2016, Tamas Berghammer wrote: > I would be happy if we can keep lldb warning free but I don't think > enabling -Werror is a good idea for 2 reasons: > * We are using a lot of different compiler and keeping the codebase > warning free on all of them might not be feasible especially for the less > used, older gcc versions. > * Neither llvm nor clang have -Werror enabled so if we enable it then a > clang/llvm change can break our build with a warning when it is hard to > justify a revert and a fix might not be trivial. > Err, sorry. I meant by default on the build bots (IIRC, some (many?) of the build bots do build with -Werror for LLVM and clang). Yes, a new warning in clang could cause issues in LLDB, though the same thing exists for the LLVM/clang dependency. Since this would be on the build bots, it should get resolved rather quickly. In short term I would prefer to just create a policy saying everybody > should write warning free code for lldb (I think it already kind of exists) > and we as a community try to ensure it during code review and with fixing > the possible things what slip through. In the longer term I would be happy > to see -Werror turned on for llvm and clang first and then we can follow up > with lldb but making this change will require a lot of discussion and might > get some push back. > > On Tue, Feb 16, 2016 at 6:02 AM Saleem Abdulrasool via lldb-dev < > lldb-dev@lists.llvm.org > > wrote: > >> Hi, >> >> It seems that enabling -Werror by default is within reach for lldb now. >> There currently are three warnings that remain with gcc 5.1 on Linux, and >> the build is clean of warnings with clang. >> >> There are two instances of type range limitations on comparisons in >> asserts, and one instance of string formatting which has a GNU >> incompatibility. >> >> Is there any interest in enabling -Werror by default to help keep the >> build clean going forward? >> >> -- >> Saleem Abdulrasool >> compnerd (at) compnerd (dot) org >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> > -- Saleem Abdulrasool compnerd (at) compnerd (dot) org ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Interest in enabling -Werror by default
On Tuesday, February 16, 2016, Tamas Berghammer wrote: > If you want to enable it only on the bots then I think we can decide it on > a bot by bot bases. For me the main question is who will be responsible for > fixing a warning introduced by a change in llvm or clang causing a build > failure because of a warning (especially when the fix is non trivial)? > I think that the same policy as LLVM/clang should apply here. The person making the change would be responsible for ensuring that nothing breaks as a result of their change. The same situation exists when working on interfaces that effect clang: a fix for a warning introduced by a change in LLVM may be non-trivial in clang. Just to be clear, I'm merely suggesting this as an option. If it is deemed too burdensome by most of the common committers, we state so and not do this. > On Tue, Feb 16, 2016 at 4:31 PM Saleem Abdulrasool > wrote: > >> On Tuesday, February 16, 2016, Tamas Berghammer > > wrote: >> >>> I would be happy if we can keep lldb warning free but I don't think >>> enabling -Werror is a good idea for 2 reasons: >>> * We are using a lot of different compiler and keeping the codebase >>> warning free on all of them might not be feasible especially for the less >>> used, older gcc versions. >>> * Neither llvm nor clang have -Werror enabled so if we enable it then a >>> clang/llvm change can break our build with a warning when it is hard to >>> justify a revert and a fix might not be trivial. >>> >> >> Err, sorry. I meant by default on the build bots (IIRC, some (many?) of >> the build bots do build with -Werror for LLVM and clang). Yes, a new >> warning in clang could cause issues in LLDB, though the same thing exists >> for the LLVM/clang dependency. Since this would be on the build bots, it >> should get resolved rather quickly. >> >> In short term I would prefer to just create a policy saying everybody >>> should write warning free code for lldb (I think it already kind of exists) >>> and we as a community try to ensure it during code review and with fixing >>> the possible things what slip through. In the longer term I would be happy >>> to see -Werror turned on for llvm and clang first and then we can follow up >>> with lldb but making this change will require a lot of discussion and might >>> get some push back. >>> >>> On Tue, Feb 16, 2016 at 6:02 AM Saleem Abdulrasool via lldb-dev < >>> lldb-dev@lists.llvm.org> wrote: >>> >>>> Hi, >>>> >>>> It seems that enabling -Werror by default is within reach for lldb >>>> now. There currently are three warnings that remain with gcc 5.1 on Linux, >>>> and the build is clean of warnings with clang. >>>> >>>> There are two instances of type range limitations on comparisons in >>>> asserts, and one instance of string formatting which has a GNU >>>> incompatibility. >>>> >>>> Is there any interest in enabling -Werror by default to help keep the >>>> build clean going forward? >>>> >>>> -- >>>> Saleem Abdulrasool >>>> compnerd (at) compnerd (dot) org >>>> ___ >>>> lldb-dev mailing list >>>> lldb-dev@lists.llvm.org >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>>> >>> >> >> -- >> Saleem Abdulrasool >> compnerd (at) compnerd (dot) org >> > -- Saleem Abdulrasool compnerd (at) compnerd (dot) org ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Interest in enabling -Werror by default
On Tue, Feb 16, 2016 at 11:01 AM, Zachary Turner wrote: > You're talking about doing it on a per-bot basis and not a global policy, > but just throwing in that on the MSVC side at least, we're not warning free > right now and it's not trivial tog et warning free without disabling some > warnings (which I don't want to do either) > Correct, it would be enabling it on a per-bot basis. We could do it such that we only enable it on bots that run a certain GCC version or newer. If at some point we become warning free on MSVC, and decide that we want to enable it on the bots so that people not building with MSVC normally know that they have introduced a warning, we could do so at that time under MSVC. Im just wondering if there is any interest in this at all. If there is, we can do this as logistically possible. It doesn't have to be all or nothing. > On Tue, Feb 16, 2016 at 10:31 AM Saleem Abdulrasool via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> On Tuesday, February 16, 2016, Tamas Berghammer >> wrote: >> >>> If you want to enable it only on the bots then I think we can decide it >>> on a bot by bot bases. For me the main question is who will be responsible >>> for fixing a warning introduced by a change in llvm or clang causing a >>> build failure because of a warning (especially when the fix is non trivial)? >>> >> >> I think that the same policy as LLVM/clang should apply here. The person >> making the change would be responsible for ensuring that nothing breaks as >> a result of their change. The same situation exists when working on >> interfaces that effect clang: a fix for a warning introduced by a change in >> LLVM may be non-trivial in clang. >> >> Just to be clear, I'm merely suggesting this as an option. If it is >> deemed too burdensome by most of the common committers, we state so and >> not do this. >> >> >> >>> On Tue, Feb 16, 2016 at 4:31 PM Saleem Abdulrasool < >>> compn...@compnerd.org> wrote: >>> >>>> On Tuesday, February 16, 2016, Tamas Berghammer >>>> wrote: >>>> >>>>> I would be happy if we can keep lldb warning free but I don't think >>>>> enabling -Werror is a good idea for 2 reasons: >>>>> * We are using a lot of different compiler and keeping the codebase >>>>> warning free on all of them might not be feasible especially for the less >>>>> used, older gcc versions. >>>>> * Neither llvm nor clang have -Werror enabled so if we enable it then >>>>> a clang/llvm change can break our build with a warning when it is hard to >>>>> justify a revert and a fix might not be trivial. >>>>> >>>> >>>> Err, sorry. I meant by default on the build bots (IIRC, some >>>> (many?) of the build bots do build with -Werror for LLVM and clang). Yes, >>>> a new warning in clang could cause issues in LLDB, though the same thing >>>> exists for the LLVM/clang dependency. Since this would be on the build >>>> bots, it should get resolved rather quickly. >>>> >>>> In short term I would prefer to just create a policy saying everybody >>>>> should write warning free code for lldb (I think it already kind of >>>>> exists) >>>>> and we as a community try to ensure it during code review and with fixing >>>>> the possible things what slip through. In the longer term I would be happy >>>>> to see -Werror turned on for llvm and clang first and then we can follow >>>>> up >>>>> with lldb but making this change will require a lot of discussion and >>>>> might >>>>> get some push back. >>>>> >>>>> On Tue, Feb 16, 2016 at 6:02 AM Saleem Abdulrasool via lldb-dev < >>>>> lldb-dev@lists.llvm.org> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> It seems that enabling -Werror by default is within reach for lldb >>>>>> now. There currently are three warnings that remain with gcc 5.1 on >>>>>> Linux, >>>>>> and the build is clean of warnings with clang. >>>>>> >>>>>> There are two instances of type range limitations on comparisons in >>>>>> asserts, and one instance of string formatting which has a GNU >>>>>> incompatibility. >>>>>> >>>>>> Is there any interest in enabling -Werror by default to help keep the >>>>>> build clean going forward? >>>>>> >>>>>> -- >>>>>> Saleem Abdulrasool >>>>>> compnerd (at) compnerd (dot) org >>>>>> ___ >>>>>> lldb-dev mailing list >>>>>> lldb-dev@lists.llvm.org >>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>>>>> >>>>> >>>> >>>> -- >>>> Saleem Abdulrasool >>>> compnerd (at) compnerd (dot) org >>>> >>> >> >> -- >> Saleem Abdulrasool >> compnerd (at) compnerd (dot) org >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> > -- Saleem Abdulrasool compnerd (at) compnerd (dot) org ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Interest in enabling -Werror by default
On Tue, Feb 16, 2016 at 12:38 PM, Kamil Rytarowski wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > NetBSD builds with GCC 4.8.2 and it emits few warnings for LLDB. > > Before enabling -Werror please first iterate over build logs and help > to squash them. For example it detects undefined behavior IIRC for a > Darwin code part. Interesting. On Linux, lldb had many warnings, and over time, I've managed to get mots of them cleaned up. Right now, there are a couple of -Wtype-limits warnings and one -Wformat warning. Is there a build bot that can be used to monitor what those warnings are? If there aren't any buildbots, then this would be of no consequence since we wouldn't turn it on for user builds. I wish I had caught what I wrote versus what I was thinking before hitting send :-(. > > On 16.02.2016 20:01, Zachary Turner via lldb-dev wrote: > > You're talking about doing it on a per-bot basis and not a global > > policy, but just throwing in that on the MSVC side at least, we're > > not warning free right now and it's not trivial tog et warning free > > without disabling some warnings (which I don't want to do either) > > > > On Tue, Feb 16, 2016 at 10:31 AM Saleem Abdulrasool via lldb-dev > > mailto:lldb-dev@lists.llvm.org>> wrote: > > > > On Tuesday, February 16, 2016, Tamas Berghammer > > mailto:tbergham...@google.com>> wrote: > > > > If you want to enable it only on the bots then I think we can > > decide it on a bot by bot bases. For me the main question is who > > will be responsible for fixing a warning introduced by a change in > > llvm or clang causing a build failure because of a warning > > (especially when the fix is non trivial)? > > > > > > I think that the same policy as LLVM/clang should apply here. The > > person making the change would be responsible for ensuring that > > nothing breaks as a result of their change. The same situation > > exists when working on interfaces that effect clang: a fix for a > > warning introduced by a change in LLVM may be non-trivial in > > clang. > > > > Just to be clear, I'm merely suggesting this as an option. If it > > is deemed too burdensome by most of the common committers, we state > > so and not do this. > > > > > > > > On Tue, Feb 16, 2016 at 4:31 PM Saleem Abdulrasool > > wrote: > > > > On Tuesday, February 16, 2016, Tamas Berghammer > > wrote: > > > > I would be happy if we can keep lldb warning free but I don't think > > enabling -Werror is a good idea for 2 reasons: * We are using a lot > > of different compiler and keeping the codebase warning free on all > > of them might not be feasible especially for the less used, older > > gcc versions. * Neither llvm nor clang have -Werror enabled so if > > we enable it then a clang/llvm change can break our build with a > > warning when it is hard to justify a revert and a fix might not be > > trivial. > > > > > > Err, sorry. I meant by default on the build bots (IIRC, some > > (many?) of the build bots do build with -Werror for LLVM and > > clang). Yes, a new warning in clang could cause issues in LLDB, > > though the same thing exists for the LLVM/clang dependency. Since > > this would be on the build bots, it should get resolved rather > > quickly. > > > > In short term I would prefer to just create a policy saying > > everybody should write warning free code for lldb (I think it > > already kind of exists) and we as a community try to ensure it > > during code review and with fixing the possible things what slip > > through. In the longer term I would be happy to see -Werror turned > > on for llvm and clang first and then we can follow up with lldb but > > making this change will require a lot of discussion and might get > > some push back. > > > > On Tue, Feb 16, 2016 at 6:02 AM Saleem Abdulrasool via lldb-dev > > wrote: > > > > Hi, > > > > It seems that enabling -Werror by default is within reach for lldb > > now. There currently are three warnings that remain with gcc 5.1 > > on Linux, and the build is clean of warnings with clang. > > > > There are two instances of type range limitations on comparisons in > > asserts, and one instance of string formatting which has a GNU > > incompatibility. > > > > Is there any interest in enabling -Werror by default to help keep > > the build clean going forward? > > > > -- Saleem Abdulrasool compnerd (at) compnerd (dot) org > > ___
Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?
On Tue, May 31, 2016 at 12:51 PM, Tim Northover via llvm-dev < llvm-...@lists.llvm.org> wrote: > On 31 May 2016 at 12:31, Renato Golin via cfe-dev > wrote: > > What do people think? Any issue not covered that we should? > > I'm in favour of the move. Git-svn just about works most of the time, > but I find it makes committing to release branches particularly > painful. It also randomly corrupts its database occasionally, just for > the giggles I assume. > I get hit by that every so often :-(. As others have mentioned, the monotonically incrementing ids are extremely useful, particularly when bisecting across clang/llvm. I think that Medhi's suggestion may be a viable solution. As long as a mechanism for bisecting across the repositories is worked out, definitely a +1 from me. > Tim. > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > -- Saleem Abdulrasool compnerd (at) compnerd (dot) org ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
On Mon, Jun 13, 2016 at 5:01 PM, Mehdi Amini via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > > On Jun 13, 2016, at 4:54 PM, Hans Wennborg wrote: > > > > Breaking this out into a separate thread since it's kind of a separate > > issue, and to make sure people see it. > > Thanks! > > > > > If you have opinions on this, please chime in. I'd like to collect as > > many arguments here as possible to make a good decision. The main > > contestants are 4.0 and 3.10, and I've seen folks being equally > > surprised by both. > > > > Brain-dump so far: > > > > - After LLVM 1.9 came 2.0, and after 2.9 came 3.0; naturally, 4.0 > > comes after 3.9. > > > > - There are special bitcode stability rules [1] concerning major > > version bumps. 2.0 and 3.0 had major IR changes, but since there > > aren't any this time, we should go to 3.10. > > > > - The bitcode stability rules allow for breakage with major versions, > > but it doesn't require it, so 4.0 is fine. > > (basically repeating my point of the other thread here) > Bumping the major version number without changing the bitcode > compatibility rule would mean dropping the current guarantee on this > aspect. I doubt we want to go this route without a good reason. > Completely agree with you here: unless we have a reason to break backwards compatibility at the bit code level for this release, I don't see a compelling reason to bump the major version number to 4.0. As such, I would expect that the next release would be 3.10. > -- > Mehdi > > > > > > - But maybe we want to save 4.0 for when we do have a significant IR > change? > > > > - We've never had an x.10 version before; maybe that would be > > confusing? Perhaps it's simply time to move on (like Linux 2.6.39 -> > > 3.0 and 3.19 -> 4.0). > > > > - Since we do time-based rather than feature-based releases, the major > > version number shouldn't mean anything special anyway (e.g. big IR > > changes or not), so 4.0? > > > > - Everyone knows that after 9 comes 10, so 3.10 it is. The version is > > a tuple after all. > > > > - Let's go for 4.0 now, and 5.0 after that. Then the "dot"-releases in > > between would correspond to minor version bumps, which would make > > sense (and catch up with GCC!). > > > > - It's just a number, no big deal; flip a coin or something. > > > > What do you think? > > > > - Hans > > > > > > [1]. > http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > -- Saleem Abdulrasool compnerd (at) compnerd (dot) org ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
On Fri, Jun 24, 2016 at 5:43 PM, Dmitri Gribenko via cfe-dev <
cfe-...@lists.llvm.org> wrote:
> On Fri, Jun 24, 2016 at 4:41 PM, Hans Wennborg via llvm-dev
> wrote:
> > Richard suggested that since we do time-based rather than
> > feature-based releases, the distinction between a release with or
> > without major changes is arbitrary, and we should move to a scheme
> > where we update the major version number on each release (4.0, 5.0,
> > etc.) with minor releases in between (4.1, 5.1, ..).
>
> If we are truly committed to doing time-based releases, we can switch
> to time-based version numbers, Year.Month, for example, if we were to
> release in June it would be 16.06. We can use an extra digit for
> minor releases.
>
This would mirror other projects doing the same, so there is precedent.
Although radically different from the current model, I think it has some
merit. When people report bugs with 3.1, its actually hard to estimate how
it is (roughly estimating it via ~6mo release cycle does really work).
This would certainly make it easier.
Its a good alternative though it does mean that we no longer have the
ability to indicate a major shift. However as Chris already pointed out,
LLVM is much more stable these days and perhaps worrying about major shifts
which are unseen is looking for a problem to solve rather than solving a
problem at hand.
+1 on this suggestion.
> Dmitri
>
> --
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Lldb-commits] LLGS for Free/NetBSD (was: Re: [PATCH] D25756: FreeBSD ARM support for software single step.)
On Mon, Oct 24, 2016 at 11:38 AM, Ed Maste via lldb-commits < lldb-comm...@lists.llvm.org> wrote: > On 24 October 2016 at 06:26, Pavel Labath wrote: > > > > It's not my place to tell you how to work, but I'd recommend a > > different approach to this. If you base your work on the current > > FreeBSD in-process plugin, then when you get around to actually > > implementing remote support, you will find that you will have to > > rewrite most of what you have already done to work with lldb-server, > > as it uses completely different class hierarchies and everything. I'd > > recommend starting with lldb-server right away. It's going to be a bit > > more work as (I assume) freebsd implementation is closer to what you > > need than linux, but I think it will save you time in the long run. I > > can help you with factoring out any linux-specific code that you > > encounter. > > I definitely second the approach Pavel suggests here, and am happy to > work with others on refactoring the Linux lldb-server so that we can > get it to support both FreeBSD and NetBSD at the same time. > > A direct port of the current FreeBSD support probably would result in > a basic level of support running sooner, but that work would be > largely thrown away in a future migration to lldb-server. > Just to throw out another option: DS2 (DebugServer2) at http://github.com/facebook/ds2 may be another option to getting remote debugging working. It already has basic BSD support, so adding NetBSD support shouldn't be too difficult. > ___ > lldb-commits mailing list > lldb-comm...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits > -- Saleem Abdulrasool compnerd (at) compnerd (dot) org ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
