Re: [lldb-dev] Patch for addressing format warnings on 32-bit
On Fri, Dec 25, 2015 at 06:34:09PM -0800, William Dillon via lldb-dev wrote: > There are a handful of -Wformat warnings on 32-bit platforms. > I addressed all those that I’ve seen while working on Swift. > Let me know if the git diff format is inappropriate for this. Don't cast size_t to uint64_t, format it with %zu directly. Joerg ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] GitHub anyone?
On Tue, May 31, 2016 at 04:24:08PM -0400, Aaron Ballman via cfe-dev wrote: > On Tue, May 31, 2016 at 3:31 PM, Renato Golin via cfe-dev > wrote: > > Folks, > > > > There has been some discussion on IRC about SVN hosting and the perils > > of doing it ourselves. The consensus on the current discussion was > > that moving to a Git-only solution would have some disvantages, but > > many advantages. Furthermore, not hosting our own repos would save us > > a lot of headaches, admin costs and timed out connections. > > Not everyone thinks git is a step forward. Please do not force people > to use a "git-only" solution. Amen. > > 2. Due to SVN, we have a mandatory time sequence, so commits go first > > in LLVM, then Clang (for example), and buildbots don't get lost. If we > > use submodules [1], we can have a similar relationship, but in a more > > explicit way, and the problem could be solved elegantly. > > I actually consider the monotonically increasing revisions to be a > feature, but not sufficient to warrant a decision one way or the > other. Has the situation with git-submodules and bisect improved at all or is bisecting clang+llvm going to be manual mess? Joerg ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?
On Tue, May 31, 2016 at 01:45:30PM -0700, Matthias Braun wrote: > To be more exact here: I usually do not checkout llvm svn at a higher > level because that forces me back to svn (which last time I used it did > not have built-in support for bisection, not sure if that changed > recently). svn-bisect is a trival tool and should be part of every good svn installation. While I never got around to script the part of "update all subrepos to the same revision", it certainly doesn't involve any addition checks. From what I can tell, git submodules don't even support that easily. I might be wrong though. Joerg ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?
On Tue, May 31, 2016 at 02:43:02PM -0700, Matthias Braun wrote: > > > On May 31, 2016, at 2:05 PM, Joerg Sonnenberger via llvm-dev > > wrote: > > > > On Tue, May 31, 2016 at 01:45:30PM -0700, Matthias Braun wrote: > >> To be more exact here: I usually do not checkout llvm svn at a higher > >> level because that forces me back to svn (which last time I used it did > >> not have built-in support for bisection, not sure if that changed > >> recently). > > > > svn-bisect is a trival tool and should be part of every good svn > > installation. While I never got around to script the part of "update all > > subrepos to the same revision", it certainly doesn't involve any > > addition checks. From what I can tell, git submodules don't even support > > that easily. I might be wrong though. > > In a nutshell: > git-submodules basically records a git revision of your submodules with the > commits. > You can make such revision switches a natural part of commits. > "git submodule update [--recursive]" will bring your submodule checkouts in > sync with what the toplevel repository expects. > > In any way we can have this discussion separate from the discussion of moving > to git. We can stay with our current ways of matching same date for now. But the move to git introduces the UI regression in first place. No date matching and the like is necessary with subversion. Joerg ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] GitHub anyone?
On Thu, Jun 02, 2016 at 04:48:36PM +0100, Renato Golin via llvm-dev wrote: > * Git developer tooling is a growing trend, while SVN tooling is > dying. This is not just about GUIs, but repository management (GitHub, > GitLab, BitBucket, etc versus SourceForge), bisects, branches, > remotes, hooks, workdir, submodules and all the new development seem > to be done on Git nowadays, not SVN. Windows may be an odd one related > to GUIs, but Visual Studio has Git integration and I hear it's similar > to the other MSVC VCSs. GitHub's desktop interface seems pretty cool, > too. I find it somewhat dishonest that the alternatives are Subversion and Git. I don't see any reason why Mercurial is excluded from the list. Given the existing Python requirement for a lot of the LLVM tooling, that part is a non-issue. It has much better Windows support. > * Web repositories make it *a lot* easier to create add-hoc pull > requests by non-developers, which could boost the number of > contributions and future contributors, as well as external projects > using LLVM components. I hear this assertion, but I don't buy it. As I said on IRC, if I follow the typical iteration process for patches from first (or even second and third) time contributors, few such patches are directly acceptable. That leaves the GitHub interface as inferior alternative to Phabricator. It seems energy would be better spend on improving the latter, e.g. by allowing registered users to trigger an integration test etc. > * Co-dependent patches already break buildbots, but the sequential ID > helps us identify and ignore. They will continue to break, even if we > use git sub-modules, so that doesn't change much, but it will be > harder to spot the issue. Server side hooks may help, as well as > sub-modules. They also make bisecting across repository boundaries much easier. I haven't heard any evidence that submodules properly deal with this. Given that one of the primary interaction with the VCS for me is bisection, anything making it more fragile or more difficult to work is a huge no. Joerg ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] GitHub anyone?
On Mon, Jun 06, 2016 at 10:32:45AM -0500, via llvm-dev wrote: > My only hesitation with this is that this requires use of cherry-pick, > which is not idea. The way most git repositories work is to put > everything that should go into a release branch in the release branch > *first* and then merge the release branch to master, ensuring that > everything going out in a release will make it into the next release. > This is how the gitflow workflow works, for example. The model of "commit to oldest first" is IMO one of the most stupid concepts I have ever seen in git "workflows". It is contrary to the way software development works and essentially just a bad workaround for broken cherry picks. I've seen more than one project starting to use this model due to advocacy after deciding to use git, stumble around with it for a release or two and then going back to a normal release management approach. Even the argument you have presented here does not make sense to me. Just because a change has been committed to a release branch, doesn't mean it won't get replaced later. Joerg ___ 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 Thu, Jun 16, 2016 at 10:02:52AM -0700, Adrian McCarthy via cfe-dev wrote: > > Most free and open-source software packages, including MediaWiki, treat > > versions as a series of individual numbers, separated by periods, with a > > progression such as 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, > > 1.11.2, and so on. On the other hand, some software packages identify > > releases by decimal numbers: 1.7, 1.8, 1.81, 1.82, 1.9, etc. > > > Note that 81 > 8, so those examples would still work. But 3.10 is easy to > misinterpret as 3.1. The only environment I know where such an interpreation is popular is CPAN. Everyone else effectively uses Dewey-style interpretation. So yes, some crappy software might mishandle 3.10 by using patterns like 3.1* and not 3.1.*, but I don't believe catering to broken software is very useful. Joerg ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] 64bit atomic ops on 32bit platforms
Hi all, there was a commit a while ago that effectively forces all LLVM projects to use libatomics on 32bit platforms. It is completely necessary for clang and LLVM, of limited usefulness for libc++ ( test cases) and necessary for LLDB right now. The only instance in LLDB is include/Utility/Timer.h for nanosecond-precise time accounting. While the code is correct, it will be secretly using a mutex in the implementation and therefore not be wait-free. This feels like somewhat of a bad idea for an accounting tool, so I would like to: (a) Make the mutex explicit if 64bit operations are not lock-free. or (b) Weaken the consistency constraints to provide eventually-consistent times by splitting the field into explicit 32bit chunks. This makes the write side get predictable timings at the expensive of the summaries being potentially off a bit in the case of races. Joerg ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] 64bit atomic ops on 32bit platforms
On Wed, Aug 02, 2017 at 03:47:56PM +0200, Joerg Sonnenberger via lldb-dev wrote: > (a) Make the mutex explicit if 64bit operations are not lock-free. > > or > > (b) Weaken the consistency constraints to provide eventually-consistent > times by splitting the field into explicit 32bit chunks. This makes the > write side get predictable timings at the expensive of the summaries > being potentially off a bit in the case of races. Ping? Given that this is a pretty annoying regression, I would like to address this for 5.0, but that means knowing how much effort I need to invest in different LLVM projects... Joerg ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged
On Tue, Aug 07, 2018 at 09:49:16PM +0200, Dimitry Andric via llvm-dev wrote: > This is a regression caused by https://reviews.llvm.org/rL323281: > > > r323281 | wmi | 2018-01-23 23:27:57 + (Tue, 23 Jan 2018) | 12 lines > > Adjust MaxAtomicInlineWidth for i386/i486 targets. > > This is to fix the bug reported in > https://bugs.llvm.org/show_bug.cgi?id=34347#c6. > Currently, all MaxAtomicInlineWidth of x86-32 targets are set to 64. However, > i386 doesn't support any cmpxchg related instructions. i486 only supports > cmpxchg. > So in this patch MaxAtomicInlineWidth is reset as follows: > For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is > supported. > For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg. > For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of > cmpxchg8b. This seems to be somewhat undesirable. Does *anyone* care about real i386 support at this point? NetBSD certainly doesn't and I think we are already the odd man for a number of cases like this. Joerg ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged
On Fri, Aug 17, 2018 at 10:27:36PM +0200, Dimitry Andric wrote: > On 16 Aug 2018, at 00:51, Joerg Sonnenberger via llvm-dev > wrote: > > On Tue, Aug 07, 2018 at 09:49:16PM +0200, Dimitry Andric via llvm-dev wrote: > >> This is a regression caused by https://reviews.llvm.org/rL323281: > >> > >> > >> r323281 | wmi | 2018-01-23 23:27:57 + (Tue, 23 Jan 2018) | 12 lines > >> > >> Adjust MaxAtomicInlineWidth for i386/i486 targets. > >> > >> This is to fix the bug reported in > >> https://bugs.llvm.org/show_bug.cgi?id=34347#c6. > >> Currently, all MaxAtomicInlineWidth of x86-32 targets are set to 64. > >> However, > >> i386 doesn't support any cmpxchg related instructions. i486 only supports > >> cmpxchg. > >> So in this patch MaxAtomicInlineWidth is reset as follows: > >> For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is > >> supported. > >> For i486, the MaxAtomicInlineWidth should be 32 because it supports > >> cmpxchg. > >> For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because > >> of cmpxchg8b. > > > > This seems to be somewhat undesirable. Does *anyone* care about real > > i386 support at this point? NetBSD certainly doesn't and I think we are > > already the odd man for a number of cases like this. > > > Yes, and since this causes quite a number of regressions for us, I would > really prefer this revision to be reverted, at least in the 7.0.0 > branch. I have already reverted it locally in our FreeBSD project > branch for importing llvm/clang 7.0.0. Hans, what is your opinion about > this? Don't get me wrong, I think the original behavior is wrong as well. It seems to me we should unconditionally assume support for cmpxchg, but not of cmpxchg8b. Accordingly, MaxAtomicInlineWidth should be 32 by default, unless Pentium+ is explicitly targetted. Joerg ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB: Unwinding based on Assembly Instruction Profiling
On Wed, Oct 14, 2015 at 11:42:06AM -0700, Greg Clayton via lldb-dev wrote: > EH frame can't be used to unwind when we are in the first frame because > it is only valid at call sites. It also can't be used in frames that > are asynchronously interrupted like signal handler frames. This is not necessarily true, GCC can build them like that. I don't think we have a flag for clang/LLVM to create full async unwind tables. Joerg ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
