Re: [Lldb-commits] [PATCH] D20436: Clean up vestigial remnants of locking primitives
compnerd added a comment. Tested against Linux-x86_64, tests state seems unchanged across the patch. @zturner you want to run another round on Windows before I merge this? https://reviews.llvm.org/D20436 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
> On Jul 18, 2016, at 8:23 PM, Tim Northover via cfe-commits > wrote: > >>> Can't handle the update of the umbrella *because of GitHub*, this could be >>> possible with our own hosting of git for instance. >>> >> Pre-commit hooks are not designed to update the umbrella. Webhooks will be >> able to update the umbrella with a small external service, as proposed in >> the IRC. > > I think we could emulate any pre-commit hook we like via GitHub > WebHooks by having two repositories: llvm and llvm-staging (say). > > People push to llvm-staging, which notifies some LLVM server we own. > That does basic sanity checks and pushes to llvm proper if passed. I think that would be terrible in practice, for instance how do you handle situations like: 1) Dev A push commit A 2) Dev B push commit B that changes some lines close to the one changed by commit A 3) sanity check fails on commit A, but llvm-staging contains A and B and can’t get rid of A easily because B would not apply without A. At this point Dev B gets an email (or other mechanism, I don’t know what you imagined) telling that his changed are rejected for no good reason. Also reverting to a state "before A” on llvm-staging would mean that that the history would be rewritten and everyone that pulled/fetched in the meantime would suffer . If we want to go towards pre-check using staging, I believe we should work with pull-request (we’d still have the issue of conflicting PR, but I don’t believe it’d be that bad in practice). That’d be welcome, but that’d also be a whole other story to setup and maintain! — Mehdi > > It has disadvantages (no instant "success" feedback being the obvious > one), but would allow us to vet commits with relatively little > overhead (as James says, running a server responding to webhooks is a > very different proposition from one hammered by hundreds of developers > daily). > > I'm not strongly in favour of this, just thought I'd mention it as a > possibility. > > Tim. > ___ > cfe-commits mailing list > cfe-comm...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
dberris added a subscriber: dberris. dberris added a comment. Mostly wording comments, thank you for writing this up! Comment at: docs/Proposals/GitHub.rst:78 @@ +77,3 @@ + +GitHub, like GitLab and BitBucket, provide FREE code hosting for open source +projects. Essentially, they will completely replace *all* the infrastructure that nit: I see you use FREE in caps but this instance isn't *FREE* (as opposed to the first mention above) -- consider making it consistent? Either remove the emphasis (just "free") or emphasise consistently? Comment at: docs/Proposals/GitHub.rst:86 @@ +85,3 @@ +for example development meetings, sponsoring disadvantaged people to work on +compilers and foster diversity and quality in our community. + Did you mean "diversity and equality" instead of "diversity and quality" here? Comment at: docs/Proposals/GitHub.rst:110-112 @@ +109,5 @@ + +As with the current SVN and Git repositories, each project will be separate, +on its own, and people will also be able to check them out in the same way +they're already doing today. + Consider rewording this sentence -- it's a little too long and is trying to say too many things. Perhaps something like: "Each LLVM project will continue to be hosted as separate GitHub repositories under a single GitHub organisation. Users can continue to choose to use either SVN or Git to access the repositories to suit their current workflow." Comment at: docs/Proposals/GitHub.rst:185 @@ +184,3 @@ + +Are there any other upstream systems that could be affected? + Probably worth mentioning how Phabricator will need to be updated to integrate with the GitHub repository once the canonical repo is changed. https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
friss added inline comments. Comment at: docs/Proposals/GitHub.rst:220 @@ +219,3 @@ +8. Tell people living downstream to pick up commits from the official git + repository. +9. Give things time to settle. We could play some games like disabling the SVN vsk wrote: > This is tricky. CC'ing @friss to comment on how we'd need to update our > internal auto-merger. This is not an issue. We were already consuming the llvm.org git repos, so we'd just need to point to the new git repos (given the git history is preserved, I don't think I've read this anywhere in this document, but I think it's safe to make this assumption) https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
>> Can't handle the update of the umbrella *because of GitHub*, this could be >> possible with our own hosting of git for instance. >> > Pre-commit hooks are not designed to update the umbrella. Webhooks will be > able to update the umbrella with a small external service, as proposed in the > IRC. I think we could emulate any pre-commit hook we like via GitHub WebHooks by having two repositories: llvm and llvm-staging (say). People push to llvm-staging, which notifies some LLVM server we own. That does basic sanity checks and pushes to llvm proper if passed. It has disadvantages (no instant "success" feedback being the obvious one), but would allow us to vet commits with relatively little overhead (as James says, running a server responding to webhooks is a very different proposition from one hammered by hundreds of developers daily). I'm not strongly in favour of this, just thought I'd mention it as a possibility. Tim. ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
vsk added subscribers: friss, vsk. vsk added a comment. @rengolin thanks for putting this together! I chimed in with some comments in-line. Comment at: docs/Proposals/GitHub.rst:68 @@ +67,3 @@ + * Collaborate with peers directly, even without access to the Internet + * Have multiple trees without multiplying disk space, multiple concurrent builds + What do you mean by multiple concurrent builds? Comment at: docs/Proposals/GitHub.rst:185 @@ +184,3 @@ + +Are there any other upstream systems that could be affected? + Yes, the `llvmlab bisect` functionality is affected. IMO it is invaluable for bug triage. Could you add some kind of reassurance that initially, updating it for the new VC model will just require pointing it to github's SVN view? Comment at: docs/Proposals/GitHub.rst:220 @@ +219,3 @@ +8. Tell people living downstream to pick up commits from the official git + repository. +9. Give things time to settle. We could play some games like disabling the SVN This is tricky. CC'ing @friss to comment on how we'd need to update our internal auto-merger. Comment at: docs/Proposals/GitHub.rst:233 @@ +232,3 @@ + +10. Collect peoples GitHub account information, adding them to the project. +11. Switch SVN repository to read-only and allow pushes to the GitHub repository. delcypher wrote: > GitHub organizations support the notion of teams which can each have > different permissions (for example you'll want to make sure only the right > people have admin access and give the rest write/read access). You could also > make a team per project so that write access in one project does not give > write access to another. I think it would be good to decide on how teams will > be organized and state this in the document. I think this is an important discussion to have once the move is under-way. I don't think finer-grained write privileges should be a part of this proposal since it's (1) a separate issue and (2) not *just* an artifact of llvm-project's svn structure (i.e there are good reasons to keep the current permissions model in place). https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
jroelofs added a subscriber: jroelofs. Comment at: docs/Proposals/GitHub.rst:127 @@ +126,3 @@ +* The projects' repositories will remain identical, with a new address (GitHub). +* They'll continue to have SVN RW access, but will also gain Git RW access. +* The linear history can still be accessed in the (RO) submodule meta project, rengolin wrote: > compnerd wrote: > > jroelofs wrote: > > > Do you mean `s/SVN RW access/SVN RO access/` here? > > I believe @rengolin is referring to the final state here. I agree that the > > current phrasing makes it hard to follow. > No, I actually mean SVN RW access. GitHub's SVN view does allow write access > to the Git repos via "svn commit". Ah, I didn't catch that part. Cool. Comment at: docs/Proposals/GitHub.rst:136 @@ +135,3 @@ +Essentially, we're adding Git RW access in addition to the already existing +structure, with all the additional benefits of it being in GitHub. + rengolin wrote: > compnerd wrote: > > jroelofs wrote: > > > Need to clarify here whether *write* access through SVN will be going > > > away. If I understand the proposal correctly, it will go away, but this > > > section makes it sound like it's staying. > > The way that I read the nutshell is that it would potentially continue to > > exist, just at a different address. > Our SVN server will die, SVN access will continue via GitHub. Ah, ok. Repository: rL LLVM https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
probinson added a subscriber: probinson. Comment at: docs/Proposals/GitHub.rst:141 @@ +140,3 @@ +has commit access to our current repository. In the future, you only need to +provide the GitHub user to be granted access. + This reads a little bit like "we will create a GitHub account for you if you don't have one" but I suspect people actually need to create their own GitHub accounts first. (We're not all on GitHub already!) https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
compnerd added inline comments. Comment at: docs/Proposals/GitHub.rst:127 @@ +126,3 @@ +* The projects' repositories will remain identical, with a new address (GitHub). +* They'll continue to have SVN RW access, but will also gain Git RW access. +* The linear history can still be accessed in the (RO) submodule meta project, jroelofs wrote: > Do you mean `s/SVN RW access/SVN RO access/` here? I believe @rengolin is referring to the final state here. I agree that the current phrasing makes it hard to follow. Comment at: docs/Proposals/GitHub.rst:129 @@ +128,3 @@ +* The linear history can still be accessed in the (RO) submodule meta project, + Which will continue to have SVN access. + "Which will continue to have SVN access" is redundant given the previous statement. Comment at: docs/Proposals/GitHub.rst:136 @@ +135,3 @@ +Essentially, we're adding Git RW access in addition to the already existing +structure, with all the additional benefits of it being in GitHub. + jroelofs wrote: > Need to clarify here whether *write* access through SVN will be going away. > If I understand the proposal correctly, it will go away, but this section > makes it sound like it's staying. The way that I read the nutshell is that it would potentially continue to exist, just at a different address. Comment at: docs/Proposals/GitHub.rst:155 @@ +154,3 @@ +But some people/companies might not be allowed to use GitHub or might have +firewalls blocking certain websites. + GitHub does have HTTPS based connections. It seems highly unlikely that this is a real concern. Companies would have to go out of their way to block access specifically to github over SSH and HTTPS. Comment at: docs/Proposals/GitHub.rst:167 @@ +166,3 @@ +with the limited number of developers whose job will be to mainly merge +thousands of patches a day. + I don't fully understand how this is any different from today. We have a core set of developers with commit access. Others are encouraged to provide patches via email (or may use phabricator depending on the reviewer). Once reviewed and accepted, one of the core developers still commits the change. I just see this as a process change. The person forks the repository on github, and creates a branch, and then a PR. The PR is reviewed and once accepted, merged by one of the core developers. It even implicitly handles authorship tracking which has currently been done in an adhoc fashion via the commit message. Comment at: docs/Proposals/GitHub.rst:222 @@ +221,3 @@ +10. Collect peoples GitHub account information, give them push access. Ideally +while still locking the GitHub repository somehow... +11. Switch SVN repository to read-only and allow pushes to the GitHub repository. Giving permissions to only the LLVM "project" is sufficient. People can be added to the LLVM "project" as collaborators and get access that way. This is similar to how Apple is managing swift for comparison. Repository: rL LLVM https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
mehdi_amini added a subscriber: mehdi_amini. Comment at: docs/Proposals/GitHub.rst:122 @@ +121,3 @@ +of understanding the *sequence* in which commits were added by using the +``git rev-list --count hash`` or ``git describe hash`` commands. + filcab wrote: > How easy will it be to clone the "aggregated" repo, and then get some (but > not all) of the submodules? I expect the umbrella repo to come with scripts for that. Comment at: docs/Proposals/GitHub.rst:129 @@ +128,3 @@ +* The linear history can still be accessed in the (RO) submodule meta project. +* Individual projects' history will be broken (linear, but local), and we need + the umbrella project (using submodules) to have the same view as we had in SVN. This sentence is not clear: "Individual projects' history will be broken", I don't see what's "broken". Comment at: docs/Proposals/GitHub.rst:168 @@ +167,3 @@ +additional benefits. + +2. Which tools will stop working? I think that's covered line 136-137. Comment at: docs/Proposals/GitHub.rst:173 @@ +172,3 @@ +use LNT with the SVN-View, but it would be best to move it to Git once and for +all. + I don't think so: LNT is not dependent on SVN history. It is dependent on a single revision number cross-repository and cross-branches. This is something that the umbrella projects "could" provide. Comment at: docs/Proposals/GitHub.rst:198 @@ +197,3 @@ +3. Make sure we have an llvm-project (with submodules) setup in the official + account. +4. Make sure bisecting with llvm-project works. Uh, this point is not clear: there will a need for us to maintain a "non-trivial" hook on our server to handle this. This is not fleshed out in this document. https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
mehdi_amini added inline comments. Comment at: docs/Proposals/GitHub.rst:209 @@ +208,3 @@ + well as a webhook to update the umbrella project (see below). +3. Make sure we have an llvm-project (with submodules) setup in the official + account, with all necessary hooks (history, update, merges). > Pre-commit hooks Won't handle the update of the umbrella. > Post-commit hooks Can't handle the update of the umbrella *because of GitHub*, this could be possible with our own hosting of git for instance. https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
mehdi_amini added inline comments. Comment at: docs/Proposals/GitHub.rst:199 @@ +198,3 @@ + +Here's a proposed plan: + Annoyingly my comment does no longer show-up next to the point it was referring to, it was about your third point: > Make sure we have an llvm-project (with submodules) setup in the official > account. I don't think how this project will be updated is explained (or even mentioned) anywhere. https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
winksaville added a subscriber: winksaville. Comment at: docs/Proposals/GitHub.rst:132 @@ +131,3 @@ + +There is no need to additional tags, flags and properties, nor of external +services controlling the history, since both SVN and *git rev-list* can already This could be worded a little better, may I suggest something like: "There is no need for additional tags, flags, properties, or external ..." https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin added inline comments. Comment at: docs/Proposals/GitHub.rst:127 @@ +126,3 @@ +* The projects' repositories will remain identical, with a new address (GitHub). +* They'll continue to have SVN RW access, but will also gain Git RW access. +* The linear history can still be accessed in the (RO) submodule meta project, jroelofs wrote: > Do you mean `s/SVN RW access/SVN RO access/` here? No, I actually mean SVN RW access. GitHub's SVN view does allow write access to the Git repos via "svn commit". Comment at: docs/Proposals/GitHub.rst:136 @@ +135,3 @@ +Essentially, we're adding Git RW access in addition to the already existing +structure, with all the additional benefits of it being in GitHub. + jroelofs wrote: > Need to clarify here whether *write* access through SVN will be going away. > If I understand the proposal correctly, it will go away, but this section > makes it sound like it's staying. Our SVN server will die, SVN access will continue via GitHub. Repository: rL LLVM https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
delcypher added a subscriber: delcypher. Comment at: docs/Proposals/GitHub.rst:102 @@ +101,3 @@ + +How will the new workflow look like +=== s/How will/What will/ Comment at: docs/Proposals/GitHub.rst:136 @@ +135,3 @@ + +We will need additional server hooks to avoid non-fast-forwards commits (ex. +merges, forced pushes, etc) in order to keep the linearity of the history. @rengolin : I know GitHub enterprise has a "protected branch" feature to prevent forced pushed ( https://github.com/blog/2051-protected-branches-and-required-status-checks ). You might want to speak to them to see if they can offer us that feature. I think there's a limited support to do a merge as a squash and rebase too ( https://github.com/blog/2141-squash-your-commits ) Comment at: docs/Proposals/GitHub.rst:233 @@ +232,3 @@ + +10. Collect peoples GitHub account information, adding them to the project. +11. Switch SVN repository to read-only and allow pushes to the GitHub repository. GitHub organizations support the notion of teams which can each have different permissions (for example you'll want to make sure only the right people have admin access and give the rest write/read access). You could also make a team per project so that write access in one project does not give write access to another. I think it would be good to decide on how teams will be organized and state this in the document. https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
mehdi_amini added inline comments. Comment at: docs/Proposals/GitHub.rst:209 @@ +208,3 @@ + well as a webhook to update the umbrella project (see below). +3. Make sure we have an llvm-project (with submodules) setup in the official + account, with all necessary hooks (history, update, merges). rengolin wrote: > mehdi_amini wrote: > > > Pre-commit hooks > > > > Won't handle the update of the umbrella. > > > > > Post-commit hooks > > > > Can't handle the update of the umbrella *because of GitHub*, this could be > > possible with our own hosting of git for instance. > > > Pre-commit hooks are not designed to update the umbrella. Webhooks will be > able to update the umbrella with a small external service, as proposed in the > IRC. That's why I asked it to be clearly mentioned somewhere else that on top of "hooks" hosted by github, we will need to maintain our own webservice on our own server to answer updates from theses hooks and update the umbrella, because that's a non-negligible drawback in face of the motivation exposed in the "Why move at all?" section. Right now the document does not acknowledge that AFAICT. https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
mehdi_amini added inline comments. Comment at: docs/Proposals/GitHub.rst:208 @@ +207,3 @@ +3. Make sure we have an llvm-project (with submodules) setup in the official + account, with all necessary hooks (history, update, merges). +4. Make sure bisecting with llvm-project works. I'd like to see clearly mentioned somewhere else than in the plan that on top of "hooks" hosted by github, we will need to maintain our own webservice on our own server to answer updates from theses hooks and update the umbrella. That's a non-negligible drawback in face of the motivation exposed in the "Why move at all?" section. https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
jroelofs added inline comments. Comment at: docs/Proposals/GitHub.rst:127 @@ +126,3 @@ +* The projects' repositories will remain identical, with a new address (GitHub). +* They'll continue to have SVN RW access, but will also gain Git RW access. +* The linear history can still be accessed in the (RO) submodule meta project, Do you mean `s/SVN RW access/SVN RO access/` here? Comment at: docs/Proposals/GitHub.rst:136 @@ +135,3 @@ +Essentially, we're adding Git RW access in addition to the already existing +structure, with all the additional benefits of it being in GitHub. + Need to clarify here whether *write* access through SVN will be going away. If I understand the proposal correctly, it will go away, but this section makes it sound like it's staying. Repository: rL LLVM https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin created this revision. rengolin added reviewers: lattner, chandlerc, jyknight, mehdi_amini, MatzeB, probinson, t.p.northover, chapuni, delcypher, dberlin, rsmith, beanz, cmatthews, asl, aaron.ballman, bcraig, Bigcheese, jroelofs, theraven, greened, hong.gyu.kim, rafael, AlexDenisov, silvas, friss, rovka, rnk. rengolin added subscribers: llvm-commits, cfe-commits, lldb-commits. rengolin set the repository for this revision to rL LLVM. This is a draft on the proposal to moving to GitHub. Once we agree if this is a good proposal, we'll create the survey to get the final and complete intent of the community and act on it. *THIS IS NOT TO AGREE ON THE DECISION*, but only to agree on the proposal, which will then fuel the decision survey. Please, avoid arguments against Git or GitHub in this review. You'll have the opportunity to do so in the survey. Dates and times can be agreed later, but we're probably looking to a 6 month period anyway. I tried to include everyone I found in Phab that was on one of the discussions, but I may have missed a few. Feel free to add more people to it, but let's try to get a reasonable agreement to the proposal (not the move) under two weeks. Repository: rL LLVM https://reviews.llvm.org/D22463 Files: docs/Proposals/GitHub.rst Index: docs/Proposals/GitHub.rst === --- /dev/null +++ docs/Proposals/GitHub.rst @@ -0,0 +1,231 @@ +== +Moving LLVM Projects to GitHub +== + +Introduction + + +This is a proposal to move our current revision control system from Subversion +to GitHub. Below are the financial and technical arguments as to why we need +such a move and how will people (and validation infrastructure) continue to work +with a Git-based LLVM. + +There will be a survey pointing at this document when we'll know the community's +reaction and, if we collectively decide to move, the time-frames. Be sure to make +your views count. + +Essentially, the proposal is divided in the following parts: + + * Outline of the reasons to move to Git and GitHub + * Description on how the work flow will look like (compared to SVN) + * Remaining issues and potential problems + * The proposed migration plan + +Why Git, and Why GitHub? + + +Why move at all? + + +The strongest reason for the move, and why this discussion started in the first +place, is that we currently host our own Subversion server and Git mirror in a +voluntary basis. The LLVM Foundation sponsors the server and provides limited +support, but there is only so much it can do. + +The volunteers are not Sysadmins themselves, but compiler engineers that happen +to know a thing or two about hosting servers. We also don't have 24/7 support, +and we sometimes wake up to see that continuous integration is broken because +the SVN server is either down or unresponsive. + +With time and money, the foundation and volunteers could improve our services, +implement more functionality and provide around the clock support, so that we +can have a first class infrastructure with which to work. But the cost is not +small, both in money and time invested. + +On the other hand, there are multiple services out there (GitHub, GitLab, +BitBucket among others) that offer that same service (24/7 stability, disk space, +Git server, code browsing, forking facilities, etc) for the very affordable price +of *FREE*. + +Why Git? + + +Most new coders nowadays start with Git. A lot of them have never used SVN, CVS +or anything else. Websites like GitHub have changed the landscape of open source +contributions, reducing the cost of first contribution and fostering +collaboration. + +Git is also the version control most LLVM developers use. Despite the sources +being stored in an SVN server, most people develop using the Git-SVN integration, +and that shows that Git is not only more powerful than SVN, but people have +resorted to using a bridge because its features are now indispensable to their +internal and external workflows. + +In essence, Git allows you to: + * Commit, squash, merge, fork locally without any penalty to the server + * Add as many branches as necessary to allow for multiple threads of development + * Collaborate with peers directly, even without access to the Internet + * Have multiple trees without multiplying disk space, multiple concurrent builds + +In addition, because Git seems to be replacing every project's version control +system, there are many more tools that can use Git's enhanced feature set, so +new tooling is much more likely to support Git first (if not only), than any +other version control system. + +Why GitHub? +--- + +GitHub, like GitLab and BitBucket, provide FREE code hosting for open source +projects. Essentially, they will completely replace *all* the infrastructure that +we have today that serves code repository, mirr
Re: [Lldb-commits] [PATCH] D22132: Support for OCaml native debugging
ebtaleb added a comment.
Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:4315
@@ +4314,3 @@
+if (die.GetLanguage() ==
lldb::eLanguageTypeOCaml) {
+location.SetLocationListSlide(0);
+} else {
From what I understood, when calculating addresses using location lists,
the location slide is computed as the absolute distance
between the function low PC and the CU low PC.
Then, in DWARFExpression, when testing whether a variable is available at a
given PC,
the Evaluate method computes the absolute address ranges of the location list
(location list offset - location list slide + function base address) and test
if
the current PC falls into that range.
The naive solution here is not maintainable here.
Is the default behaviour due to something specific to the way Clang generates
location list offsets?
What is the use of location slides when calculating location list addresses?
Can I overwrite location slide setting with a custom DWARF parser?
Or should I include the slide offset in the location list generation in the
compiler itself?
https://reviews.llvm.org/D22132
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r275944 - Ignore clang-module-cache directories that may be created
Author: jmolenda Date: Mon Jul 18 21:37:07 2016 New Revision: 275944 URL: http://llvm.org/viewvc/llvm-project?rev=275944&view=rev Log: Ignore clang-module-cache directories that may be created in the testsuite directory while it runs. Modified: lldb/trunk/.gitignore Modified: lldb/trunk/.gitignore URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/.gitignore?rev=275944&r1=275943&r2=275944&view=diff == --- lldb/trunk/.gitignore (original) +++ lldb/trunk/.gitignore Mon Jul 18 21:37:07 2016 @@ -36,6 +36,8 @@ ninja/ test/20* __pycache__/ +clang-module-cache + # We should ignore Xcode-style embedding of llvm/ at lldb root dir. # Do not add trailing '/'s, they skip symlinks. /llvm ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D20436: Clean up vestigial remnants of locking primitives
compnerd added a comment.
Ugh, yeah, I had forgotten about this. Ill try to get to this tonight/tomorrow.
Comment at: source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:354-355
@@ -358,5 +353,4 @@
{
-// Calculate absolute timeout value
-TimeValue timeout = TimeValue::Now();
-timeout.OffsetWithMicroSeconds(timeout_usec);
+std::chrono::time_point until =
+std::chrono::system_clock::now() +
std::chrono::microseconds(timeout_usec);
zturner wrote:
> Need to use `auto` here, otherwise there's a compiler error.
Yeah, noticed that on Linux; Ill upload a new version of the patch. I ended up
just doing the math in a second step.
Comment at:
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp:844
@@ -845,1 +843,3 @@
+if (m_async_packet_predicate.WaitForValueEqualTo(
+false, until -
std::chrono::system_clock::now(), &timed_out))
{
zturner wrote:
> this needs to use
> `std::chrono::duration_cast(until -
> std::chrono::system_clock::now())`. Maybe raise this into a temporary
> variable (also make sure to use auto on the result just in case).
Yeah, hoisting that into a local var sounds good.
Comment at:
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp:860
@@ -859,2 +859,3 @@
// Make sure we wait until the continue packet has
been sent again...
-if (m_private_is_running.WaitForValueEqualTo (true,
&timeout_time, &timed_out))
+if (m_private_is_running.WaitForValueEqualTo(true,
until - std::chrono::system_clock::now(),
+
&timed_out))
zturner wrote:
> `duration_cast` again.
Yeah.
Comment at: source/Target/Process.cpp:5547
@@ +5546,3 @@
+log->Printf("Process::RunThreadPlan(): about to wait - now
is %llu - endpoint is %llu",
+
std::chrono::time_point(
+std::chrono::system_clock::now())
zturner wrote:
> Delete the cast here. Just use `std::chrono::system_clock::now()`.
Yeah.
Comment at: source/Target/Process.cpp:5551
@@ +5550,3 @@
+.count(),
+
std::chrono::time_point(timeout)
+.time_since_epoch()
zturner wrote:
> Change to `timeout.time_since_epoch()`
This doesn't work for me. `timeout` is a `std::duration`, and
`std::time_point` is needed.
Repository:
rL LLVM
https://reviews.llvm.org/D20436
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D20436: Clean up vestigial remnants of locking primitives
compnerd added a comment. *hadn't Repository: rL LLVM https://reviews.llvm.org/D20436 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
jyknight added a subscriber: jyknight. Comment at: docs/Proposals/GitHub.rst:209 @@ +208,3 @@ + well as a webhook to update the umbrella project (see below). +3. Make sure we have an llvm-project (with submodules) setup in the official + account, with all necessary hooks (history, update, merges). mehdi_amini wrote: > rengolin wrote: > > mehdi_amini wrote: > > > > Pre-commit hooks > > > > > > Won't handle the update of the umbrella. > > > > > > > Post-commit hooks > > > > > > Can't handle the update of the umbrella *because of GitHub*, this could > > > be possible with our own hosting of git for instance. > > > > > Pre-commit hooks are not designed to update the umbrella. Webhooks will be > > able to update the umbrella with a small external service, as proposed in > > the IRC. > That's why I asked it to be clearly mentioned somewhere else that on top of > "hooks" hosted by github, we will need to maintain our own webservice on our > own server to answer updates from theses hooks and update the umbrella, > because that's a non-negligible drawback in face of the motivation exposed in > the "Why move at all?" section. > Right now the document does not acknowledge that AFAICT. The maintenance of that service will be negligible compared to running a subversion installation. I expect that we could set up the webhook as an AppEngine app, using Github's "Git Data" API to generate the new commit, and then to the first approximation never have to touch it again. https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin added inline comments. Comment at: docs/Proposals/GitHub.rst:209 @@ +208,3 @@ + well as a webhook to update the umbrella project (see below). +3. Make sure we have an llvm-project (with submodules) setup in the official + account, with all necessary hooks (history, update, merges). mehdi_amini wrote: > > Pre-commit hooks > > Won't handle the update of the umbrella. > > > Post-commit hooks > > Can't handle the update of the umbrella *because of GitHub*, this could be > possible with our own hosting of git for instance. > Pre-commit hooks are not designed to update the umbrella. Webhooks will be able to update the umbrella with a small external service, as proposed in the IRC. https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin updated this revision to Diff 64383. rengolin added a comment. Expand step 2 to make sure we don't forget about the safety hooks on each project as well as the webhook to update the umbrella project. This could turn out to be a buildbot, but makes no difference at this stage. https://reviews.llvm.org/D22463 Files: docs/Proposals/GitHub.rst Index: docs/Proposals/GitHub.rst === --- /dev/null +++ docs/Proposals/GitHub.rst @@ -0,0 +1,242 @@ +== +Moving LLVM Projects to GitHub +== + +Introduction + + +This is a proposal to move our current revision control system from our own +hosted Subversion to GitHub. Below are the financial and technical arguments as +to why we need such a move and how will people (and validation infrastructure) +continue to work with a Git-based LLVM. + +There will be a survey pointing at this document when we'll know the community's +reaction and, if we collectively decide to move, the time-frames. Be sure to make +your views count. + +Essentially, the proposal is divided in the following parts: + + * Outline of the reasons to move to Git and GitHub + * Description on how the work flow will look like (compared to SVN) + * Remaining issues and potential problems + * The proposed migration plan + +Why Git, and Why GitHub? + + +Why move at all? + + +The strongest reason for the move, and why this discussion started in the first +place, is that we currently host our own Subversion server and Git mirror in a +voluntary basis. The LLVM Foundation sponsors the server and provides limited +support, but there is only so much it can do. + +The volunteers are not Sysadmins themselves, but compiler engineers that happen +to know a thing or two about hosting servers. We also don't have 24/7 support, +and we sometimes wake up to see that continuous integration is broken because +the SVN server is either down or unresponsive. + +With time and money, the foundation and volunteers could improve our services, +implement more functionality and provide around the clock support, so that we +can have a first class infrastructure with which to work. But the cost is not +small, both in money and time invested. + +On the other hand, there are multiple services out there (GitHub, GitLab, +BitBucket among others) that offer that same service (24/7 stability, disk space, +Git server, code browsing, forking facilities, etc) for the very affordable price +of *FREE*. + +Why Git? + + +Most new coders nowadays start with Git. A lot of them have never used SVN, CVS +or anything else. Websites like GitHub have changed the landscape of open source +contributions, reducing the cost of first contribution and fostering +collaboration. + +Git is also the version control most LLVM developers use. Despite the sources +being stored in an SVN server, most people develop using the Git-SVN integration, +and that shows that Git is not only more powerful than SVN, but people have +resorted to using a bridge because its features are now indispensable to their +internal and external workflows. + +In essence, Git allows you to: + * Commit, squash, merge, fork locally without any penalty to the server + * Add as many branches as necessary to allow for multiple threads of development + * Collaborate with peers directly, even without access to the Internet + * Have multiple trees without multiplying disk space, multiple concurrent builds + +In addition, because Git seems to be replacing every project's version control +system, there are many more tools that can use Git's enhanced feature set, so +new tooling is much more likely to support Git first (if not only), than any +other version control system. + +Why GitHub? +--- + +GitHub, like GitLab and BitBucket, provide FREE code hosting for open source +projects. Essentially, they will completely replace *all* the infrastructure that +we have today that serves code repository, mirroring, user control, etc. + +They also have a dedicated team to monitor, migrate, improve and distribute the +contents of the repositories depending on region and load. A level of quality +that we'd never have without spending money that would be better spent elsewhere, +for example development meetings, sponsoring disadvantaged people to work on +compilers and foster diversity and quality in our community. + +GitHub has the added benefit that we already have a presence there. Many +developers use it already, and the mirror from our current repository is already +set up. + +Furthermore, GitHub has an *SVN view* (https://github.com/blog/626-announcing-svn-support) +where people that still have/want to use SVN infrastructure and tooling can +slowly migrate or even stay working as if it was an SVN repository (including +read-write access). + +So, any of the three solutions solve the cost and maintenance problem, but
[Lldb-commits] [lldb] r275914 - Add missing headers after header cleanup in r275882.
Author: chaoren Date: Mon Jul 18 16:11:43 2016 New Revision: 275914 URL: http://llvm.org/viewvc/llvm-project?rev=275914&view=rev Log: Add missing headers after header cleanup in r275882. Modified: lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp Modified: lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp?rev=275914&r1=275913&r2=275914&view=diff == --- lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp (original) +++ lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp Mon Jul 18 16:11:43 2016 @@ -16,9 +16,11 @@ #include "clang/Frontend/CompilerInstance.h" #include "clang/Frontend/FrontendActions.h" #include "clang/Lex/Preprocessor.h" +#include "clang/Lex/PreprocessorOptions.h" #include "clang/Parse/Parser.h" #include "clang/Sema/Lookup.h" #include "clang/Serialization/ASTReader.h" +#include "llvm/Support/Path.h" // Project includes #include "ClangModulesDeclVendor.h" ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin added inline comments. Comment at: docs/Proposals/GitHub.rst:208 @@ +207,3 @@ +3. Make sure we have an llvm-project (with submodules) setup in the official + account, with all necessary hooks (history, update, merges). +4. Make sure bisecting with llvm-project works. mehdi_amini wrote: > I'd like to see clearly mentioned somewhere else than in the plan that on top > of "hooks" hosted by github, we will need to maintain our own webservice on > our own server to answer updates from theses hooks and update the umbrella. > That's a non-negligible drawback in face of the motivation exposed in the > "Why move at all?" section. There are two types of hooks: 1. Pre-commit hooks that will stop anyone trying to merge/force push commits to the projects, in order to keep the history clean. These are install once, use forever. Zero maintenance after the initial period. 2. Post-commit hooks on the other projects / OR / external webservice/buildbot that will update the umbrella project like any existing Git mirror. Maintenance of this is either free (hooks) or very cheap (buildbot/cron jobs). On both cases, the history is preserved at least within the update cycle, which shouldn't be more than 5 minutes, and will be the update cycle that buildbots will pick the commits anyway. https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] LLVM buildmaster will be restarted tonight
Hello everyone, LLVM buildmaster will be updated and restarted after 7 PM Pacific time today. Thanks Galina ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin added inline comments. Comment at: docs/Proposals/GitHub.rst:200 @@ +199,3 @@ + +Here's a proposed plan: + You can click on the "<<" button and it will show where it was first inserted. That's how I found out. :) The hooks, AFAICS, will be added to the project initially, and won't need to be updated. Takumi's current repository is automatically updated, and IIRC, it's just a hook. Assuming it's atomic and quick enough, would this process make much of a difference to the users? https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin updated this revision to Diff 64373. rengolin added a comment. Removing "broken" to describe the history, just explaining it'll be local. Expanding to mention that hooks will need to be implemented in step 3. https://reviews.llvm.org/D22463 Files: docs/Proposals/GitHub.rst Index: docs/Proposals/GitHub.rst === --- /dev/null +++ docs/Proposals/GitHub.rst @@ -0,0 +1,240 @@ +== +Moving LLVM Projects to GitHub +== + +Introduction + + +This is a proposal to move our current revision control system from our own +hosted Subversion to GitHub. Below are the financial and technical arguments as +to why we need such a move and how will people (and validation infrastructure) +continue to work with a Git-based LLVM. + +There will be a survey pointing at this document when we'll know the community's +reaction and, if we collectively decide to move, the time-frames. Be sure to make +your views count. + +Essentially, the proposal is divided in the following parts: + + * Outline of the reasons to move to Git and GitHub + * Description on how the work flow will look like (compared to SVN) + * Remaining issues and potential problems + * The proposed migration plan + +Why Git, and Why GitHub? + + +Why move at all? + + +The strongest reason for the move, and why this discussion started in the first +place, is that we currently host our own Subversion server and Git mirror in a +voluntary basis. The LLVM Foundation sponsors the server and provides limited +support, but there is only so much it can do. + +The volunteers are not Sysadmins themselves, but compiler engineers that happen +to know a thing or two about hosting servers. We also don't have 24/7 support, +and we sometimes wake up to see that continuous integration is broken because +the SVN server is either down or unresponsive. + +With time and money, the foundation and volunteers could improve our services, +implement more functionality and provide around the clock support, so that we +can have a first class infrastructure with which to work. But the cost is not +small, both in money and time invested. + +On the other hand, there are multiple services out there (GitHub, GitLab, +BitBucket among others) that offer that same service (24/7 stability, disk space, +Git server, code browsing, forking facilities, etc) for the very affordable price +of *FREE*. + +Why Git? + + +Most new coders nowadays start with Git. A lot of them have never used SVN, CVS +or anything else. Websites like GitHub have changed the landscape of open source +contributions, reducing the cost of first contribution and fostering +collaboration. + +Git is also the version control most LLVM developers use. Despite the sources +being stored in an SVN server, most people develop using the Git-SVN integration, +and that shows that Git is not only more powerful than SVN, but people have +resorted to using a bridge because its features are now indispensable to their +internal and external workflows. + +In essence, Git allows you to: + * Commit, squash, merge, fork locally without any penalty to the server + * Add as many branches as necessary to allow for multiple threads of development + * Collaborate with peers directly, even without access to the Internet + * Have multiple trees without multiplying disk space, multiple concurrent builds + +In addition, because Git seems to be replacing every project's version control +system, there are many more tools that can use Git's enhanced feature set, so +new tooling is much more likely to support Git first (if not only), than any +other version control system. + +Why GitHub? +--- + +GitHub, like GitLab and BitBucket, provide FREE code hosting for open source +projects. Essentially, they will completely replace *all* the infrastructure that +we have today that serves code repository, mirroring, user control, etc. + +They also have a dedicated team to monitor, migrate, improve and distribute the +contents of the repositories depending on region and load. A level of quality +that we'd never have without spending money that would be better spent elsewhere, +for example development meetings, sponsoring disadvantaged people to work on +compilers and foster diversity and quality in our community. + +GitHub has the added benefit that we already have a presence there. Many +developers use it already, and the mirror from our current repository is already +set up. + +Furthermore, GitHub has an *SVN view* (https://github.com/blog/626-announcing-svn-support) +where people that still have/want to use SVN infrastructure and tooling can +slowly migrate or even stay working as if it was an SVN repository (including +read-write access). + +So, any of the three solutions solve the cost and maintenance problem, but GitHub +has two additional features that would be beneficial to the m
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin added inline comments. Comment at: docs/Proposals/GitHub.rst:198 @@ +197,3 @@ +3. Make sure we have an llvm-project (with submodules) setup in the official + account. +4. Make sure bisecting with llvm-project works. mehdi_amini wrote: > Uh, this point is not clear: there will a need for us to maintain a > "non-trivial" hook on our server to handle this. This is not fleshed out in > this document. Good point. I added just a description to this topic, since this is covered elsewhere. Comment at: docs/Proposals/GitHub.rst:174 @@ +173,3 @@ +us what's wrong and how to help them fix it. + +We also recommend people and companies to migrate to Git, for its many other So, LNT migration plan could be: 1. Use GitHub's SVN view on llvm-proj-submods 2. Move to understand submods 3. Migrate all instances Looks fairly orthogonal to me... https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin updated this revision to Diff 64371. rengolin added a comment. Second round of suggestions applied. https://reviews.llvm.org/D22463 Files: docs/Proposals/GitHub.rst Index: docs/Proposals/GitHub.rst === --- /dev/null +++ docs/Proposals/GitHub.rst @@ -0,0 +1,239 @@ +== +Moving LLVM Projects to GitHub +== + +Introduction + + +This is a proposal to move our current revision control system from our own +hosted Subversion to GitHub. Below are the financial and technical arguments as +to why we need such a move and how will people (and validation infrastructure) +continue to work with a Git-based LLVM. + +There will be a survey pointing at this document when we'll know the community's +reaction and, if we collectively decide to move, the time-frames. Be sure to make +your views count. + +Essentially, the proposal is divided in the following parts: + + * Outline of the reasons to move to Git and GitHub + * Description on how the work flow will look like (compared to SVN) + * Remaining issues and potential problems + * The proposed migration plan + +Why Git, and Why GitHub? + + +Why move at all? + + +The strongest reason for the move, and why this discussion started in the first +place, is that we currently host our own Subversion server and Git mirror in a +voluntary basis. The LLVM Foundation sponsors the server and provides limited +support, but there is only so much it can do. + +The volunteers are not Sysadmins themselves, but compiler engineers that happen +to know a thing or two about hosting servers. We also don't have 24/7 support, +and we sometimes wake up to see that continuous integration is broken because +the SVN server is either down or unresponsive. + +With time and money, the foundation and volunteers could improve our services, +implement more functionality and provide around the clock support, so that we +can have a first class infrastructure with which to work. But the cost is not +small, both in money and time invested. + +On the other hand, there are multiple services out there (GitHub, GitLab, +BitBucket among others) that offer that same service (24/7 stability, disk space, +Git server, code browsing, forking facilities, etc) for the very affordable price +of *FREE*. + +Why Git? + + +Most new coders nowadays start with Git. A lot of them have never used SVN, CVS +or anything else. Websites like GitHub have changed the landscape of open source +contributions, reducing the cost of first contribution and fostering +collaboration. + +Git is also the version control most LLVM developers use. Despite the sources +being stored in an SVN server, most people develop using the Git-SVN integration, +and that shows that Git is not only more powerful than SVN, but people have +resorted to using a bridge because its features are now indispensable to their +internal and external workflows. + +In essence, Git allows you to: + * Commit, squash, merge, fork locally without any penalty to the server + * Add as many branches as necessary to allow for multiple threads of development + * Collaborate with peers directly, even without access to the Internet + * Have multiple trees without multiplying disk space, multiple concurrent builds + +In addition, because Git seems to be replacing every project's version control +system, there are many more tools that can use Git's enhanced feature set, so +new tooling is much more likely to support Git first (if not only), than any +other version control system. + +Why GitHub? +--- + +GitHub, like GitLab and BitBucket, provide FREE code hosting for open source +projects. Essentially, they will completely replace *all* the infrastructure that +we have today that serves code repository, mirroring, user control, etc. + +They also have a dedicated team to monitor, migrate, improve and distribute the +contents of the repositories depending on region and load. A level of quality +that we'd never have without spending money that would be better spent elsewhere, +for example development meetings, sponsoring disadvantaged people to work on +compilers and foster diversity and quality in our community. + +GitHub has the added benefit that we already have a presence there. Many +developers use it already, and the mirror from our current repository is already +set up. + +Furthermore, GitHub has an *SVN view* (https://github.com/blog/626-announcing-svn-support) +where people that still have/want to use SVN infrastructure and tooling can +slowly migrate or even stay working as if it was an SVN repository (including +read-write access). + +So, any of the three solutions solve the cost and maintenance problem, but GitHub +has two additional features that would be beneficial to the migration plan as +well as the community already settled there. + + +How will the new workflow look like +=
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin added inline comments.
Comment at: docs/Proposals/GitHub.rst:8-9
@@ +7,4 @@
+
+This is a proposal to move our current revision control system from Subversion
+to GitHub. Below are the financial and technical arguments as to why we need
+such a move and how will people (and validation infrastructure) continue to
work
emaste wrote:
> It seems pedantic, but I think we should try hard to avoid conflating Git and
> GitHub. What about: "move our revision control system from //self-hosted//
> Subversion to Git hosted by GitHub."
This is a summary of the whole proposal, which specifically dictates GitHub.
We're not proposing to move to some Git hosting anymore, but exactly GitHub,
due to the constraints that we outline below. If we do not move to GitHub
specifically, a lot of the assumptions below will be wrong, and this proposal
can't be accepted.
There is a paragraph on why git, and another on why GitHub, and both are key
points of this proposal.
I'll change "from Subversion" to "from our own hosted Subversion" to make that
even more clear.
Comment at: docs/Proposals/GitHub.rst:93
@@ +92,3 @@
+Furthermore, GitHub has an *SVN view*
(https://github.com/blog/626-announcing-svn-support)
+where people stuck with SVN infrastructure and tooling can slowly migrate or
+even stay working as if it was an SVN repository (including read-write access).
emaste wrote:
> Replace "stuck" with something neutral. "stuck" implies that everyone will
> want to move but some may not be able to for technical or other reasons, but
> some people actually prefer SVN.
good point.
Comment at: docs/Proposals/GitHub.rst:122
@@ +121,3 @@
+of understanding the *sequence* in which commits were added by using the
+``git rev-list --count hash`` or ``git describe hash`` commands.
+
filcab wrote:
> How easy will it be to clone the "aggregated" repo, and then get some (but
> not all) of the submodules?
Checking out this project:
https://github.com/chapuni/llvm-project-submodule
Will return the references, not the sub modules. You have to "init" each
sub-module independently, which achieves the same task as only checking out the
SVN repos you need, with the correct numbering.
Comment at: docs/Proposals/GitHub.rst:130
@@ +129,3 @@
+* Individual projects' history will be broken (linear, but local), and we need
+ the umbrella project (using submodules) to have the same view as we had in
SVN.
+
filcab wrote:
> I wouldn't call it broken.
> Won't it have the same end result as having a checkout per project and simply
> updating them close to each other?
>
> Basically, it won't be "any more broken" than using this method for updating:
>
> ```
> #!/bin/bash
> for dir in llvm/{,tools/{clang,lld},projects/{libcxx,libcxxabi,compiler-rt}};
> do
> # (cd $dir && svn up) # for SVN
> (cd $dir && git checkout master && git pull) # for git
> done
> ```
No, it won't.
Checking out LLVM only skips all commits from all other repos. So, for example:
LNT 123
Clang 124
RT 125
LLVM 126
Then, "svn checkout 126" will be:
In LNT, 123 as 126
In Clang, 124 as 126
In RT, 125 as 126
In LLVM, 126 as 126
With the new SVN interface, each one of those commits will be referred to,
locally, as 123, and 126 will not exist, because the "git rev-list --count"
won't get as high as 126.
However, on the umbrella submodule project, because the sequence of the commits
is guaranteed, the rev-list count will bring the correct numbering, the same as
via the SVN interface, and thus be "just like SVN was".
Comment at: docs/Proposals/GitHub.rst:132
@@ +131,3 @@
+
+There is no need to additional tags, flags and properties, nor of external
+services controlling the history, since both SVN and *git rev-list* can already
winksaville wrote:
> This could be worded a little better, may I suggest something like:
>
> "There is no need for additional tags, flags, properties, or external ..."
>
Yup, changing on next round. Thanks!
Comment at: docs/Proposals/GitHub.rst:141
@@ +140,3 @@
+has commit access to our current repository. In the future, you only need to
+provide the GitHub user to be granted access.
+
probinson wrote:
> This reads a little bit like "we will create a GitHub account for you if you
> don't have one" but I suspect people actually need to create their own GitHub
> accounts first. (We're not all on GitHub already!)
well, "you need to provide the GitHub user" should take care of that, but I'll
try to re-write this to make it more clear.
> (We're not all on GitHub already!)
Are we not? Egregious! :D
Comment at: docs/Proposals/GitHub.rst:180
@@ +179,3 @@
+
+As soon as we decide to move, we'll have to set a date for the process to
begin.
+
emaste wrote:
> This presents it
[Lldb-commits] [lldb] r275885 - make macOS 'launch in terminal' bring terminal to the front during launch
Author: tfiala Date: Mon Jul 18 14:15:38 2016 New Revision: 275885 URL: http://llvm.org/viewvc/llvm-project?rev=275885&view=rev Log: make macOS 'launch in terminal' bring terminal to the front during launch rdar://25235812 Modified: lldb/trunk/source/Host/macosx/Host.mm Modified: lldb/trunk/source/Host/macosx/Host.mm URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/macosx/Host.mm?rev=275885&r1=275884&r2=275885&view=diff == --- lldb/trunk/source/Host/macosx/Host.mm (original) +++ lldb/trunk/source/Host/macosx/Host.mm Mon Jul 18 14:15:38 2016 @@ -362,6 +362,7 @@ WaitForProcessToSIGSTOP (const lldb::pid const char *applscript_in_new_tty = "tell application \"Terminal\"\n" +" activate\n" " do script \"%s\"\n" "end tell\n"; ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
emaste added a subscriber: emaste. Comment at: docs/Proposals/GitHub.rst:8-9 @@ +7,4 @@ + +This is a proposal to move our current revision control system from Subversion +to GitHub. Below are the financial and technical arguments as to why we need +such a move and how will people (and validation infrastructure) continue to work It seems pedantic, but I think we should try hard to avoid conflating Git and GitHub. What about: "move our revision control system from //self-hosted// Subversion to Git hosted by GitHub." Comment at: docs/Proposals/GitHub.rst:93 @@ +92,3 @@ +Furthermore, GitHub has an *SVN view* (https://github.com/blog/626-announcing-svn-support) +where people stuck with SVN infrastructure and tooling can slowly migrate or +even stay working as if it was an SVN repository (including read-write access). Replace "stuck" with something neutral. "stuck" implies that everyone will want to move but some may not be able to for technical or other reasons, but some people actually prefer SVN. Comment at: docs/Proposals/GitHub.rst:180 @@ +179,3 @@ + +As soon as we decide to move, we'll have to set a date for the process to begin. + This presents it as if the decision is already made, which somewhat defeats the purpose of writing a proposal for the LLVM community to vote on. Maybe "If we decide to move"? https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
filcab added a subscriber: filcab.
filcab added a comment.
What about branches? I'm guessing we should expect the usual release branches.
But will any person be able to create a branch? Will there be a policy, if this
is the case? Is the policy enforceable?
Comment at: docs/Proposals/GitHub.rst:122
@@ +121,3 @@
+of understanding the *sequence* in which commits were added by using the
+``git rev-list --count hash`` or ``git describe hash`` commands.
+
How easy will it be to clone the "aggregated" repo, and then get some (but not
all) of the submodules?
Comment at: docs/Proposals/GitHub.rst:130
@@ +129,3 @@
+* Individual projects' history will be broken (linear, but local), and we need
+ the umbrella project (using submodules) to have the same view as we had in
SVN.
+
I wouldn't call it broken.
Won't it have the same end result as having a checkout per project and simply
updating them close to each other?
Basically, it won't be "any more broken" than using this method for updating:
```
#!/bin/bash
for dir in llvm/{,tools/{clang,lld},projects/{libcxx,libcxxabi,compiler-rt}}; do
# (cd $dir && svn up) # for SVN
(cd $dir && git checkout master && git pull) # for git
done
```
https://reviews.llvm.org/D22463
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin removed rL LLVM as the repository for this revision. rengolin updated this revision to Diff 64334. rengolin added a comment. First round of changes reflecting reviews. https://reviews.llvm.org/D22463 Files: docs/Proposals/GitHub.rst Index: docs/Proposals/GitHub.rst === --- /dev/null +++ docs/Proposals/GitHub.rst @@ -0,0 +1,230 @@ +== +Moving LLVM Projects to GitHub +== + +Introduction + + +This is a proposal to move our current revision control system from Subversion +to GitHub. Below are the financial and technical arguments as to why we need +such a move and how will people (and validation infrastructure) continue to work +with a Git-based LLVM. + +There will be a survey pointing at this document when we'll know the community's +reaction and, if we collectively decide to move, the time-frames. Be sure to make +your views count. + +Essentially, the proposal is divided in the following parts: + + * Outline of the reasons to move to Git and GitHub + * Description on how the work flow will look like (compared to SVN) + * Remaining issues and potential problems + * The proposed migration plan + +Why Git, and Why GitHub? + + +Why move at all? + + +The strongest reason for the move, and why this discussion started in the first +place, is that we currently host our own Subversion server and Git mirror in a +voluntary basis. The LLVM Foundation sponsors the server and provides limited +support, but there is only so much it can do. + +The volunteers are not Sysadmins themselves, but compiler engineers that happen +to know a thing or two about hosting servers. We also don't have 24/7 support, +and we sometimes wake up to see that continuous integration is broken because +the SVN server is either down or unresponsive. + +With time and money, the foundation and volunteers could improve our services, +implement more functionality and provide around the clock support, so that we +can have a first class infrastructure with which to work. But the cost is not +small, both in money and time invested. + +On the other hand, there are multiple services out there (GitHub, GitLab, +BitBucket among others) that offer that same service (24/7 stability, disk space, +Git server, code browsing, forking facilities, etc) for the very affordable price +of *FREE*. + +Why Git? + + +Most new coders nowadays start with Git. A lot of them have never used SVN, CVS +or anything else. Websites like GitHub have changed the landscape of open source +contributions, reducing the cost of first contribution and fostering +collaboration. + +Git is also the version control most LLVM developers use. Despite the sources +being stored in an SVN server, most people develop using the Git-SVN integration, +and that shows that Git is not only more powerful than SVN, but people have +resorted to using a bridge because its features are now indispensable to their +internal and external workflows. + +In essence, Git allows you to: + * Commit, squash, merge, fork locally without any penalty to the server + * Add as many branches as necessary to allow for multiple threads of development + * Collaborate with peers directly, even without access to the Internet + * Have multiple trees without multiplying disk space, multiple concurrent builds + +In addition, because Git seems to be replacing every project's version control +system, there are many more tools that can use Git's enhanced feature set, so +new tooling is much more likely to support Git first (if not only), than any +other version control system. + +Why GitHub? +--- + +GitHub, like GitLab and BitBucket, provide FREE code hosting for open source +projects. Essentially, they will completely replace *all* the infrastructure that +we have today that serves code repository, mirroring, user control, etc. + +They also have a dedicated team to monitor, migrate, improve and distribute the +contents of the repositories depending on region and load. A level of quality +that we'd never have without spending money that would be better spent elsewhere, +for example development meetings, sponsoring disadvantaged people to work on +compilers and foster diversity and quality in our community. + +GitHub has the added benefit that we already have a presence there. Many +developers use it already, and the mirror from our current repository is already +set up. + +Furthermore, GitHub has an *SVN view* (https://github.com/blog/626-announcing-svn-support) +where people stuck with SVN infrastructure and tooling can slowly migrate or +even stay working as if it was an SVN repository (including read-write access). + +So, any of the three solutions solve the cost and maintenance problem, but GitHub +has two additional features that would be beneficial to the migration plan as +well as the community already settled there. + + +How wil
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
compnerd added inline comments. Comment at: docs/Proposals/GitHub.rst:167 @@ +166,3 @@ +with the limited number of developers whose job will be to mainly merge +thousands of patches a day. + rengolin wrote: > compnerd wrote: > > I don't fully understand how this is any different from today. We have a > > core set of developers with commit access. Others are encouraged to > > provide patches via email (or may use phabricator depending on the > > reviewer). Once reviewed and accepted, one of the core developers still > > commits the change. I just see this as a process change. > > > > The person forks the repository on github, and creates a branch, and then a > > PR. The PR is reviewed and once accepted, merged by one of the core > > developers. It even implicitly handles authorship tracking which has > > currently been done in an adhoc fashion via the commit message. > Today we all commit to SVN, which is linear. In GitHub, we'll be committing > to git. If we can have hooks forbidding merges, it'll remain linear, but then > pull requests will be blocked. Additional hooks will need to be in place > (please suggest all of them here and I'll update the doc). I think that we should aim to preserve the linearity of history. This would mean that we block non-fastforward commits (i.e. no merges, no force pushes). Repository: rL LLVM https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin added inline comments. Comment at: docs/Proposals/GitHub.rst:129 @@ +128,3 @@ +* The linear history can still be accessed in the (RO) submodule meta project, + Which will continue to have SVN access. + compnerd wrote: > "Which will continue to have SVN access" is redundant given the previous > statement. good point. I'll try and re-write those points to be more clear. Comment at: docs/Proposals/GitHub.rst:155 @@ +154,3 @@ +But some people/companies might not be allowed to use GitHub or might have +firewalls blocking certain websites. + compnerd wrote: > GitHub does have HTTPS based connections. It seems highly unlikely that this > is a real concern. Companies would have to go out of their way to block > access specifically to github over SSH and HTTPS. I have had this problem in China... Though no one has raised this issue, so I'll just remove and let people complain about this in the survey. Comment at: docs/Proposals/GitHub.rst:167 @@ +166,3 @@ +with the limited number of developers whose job will be to mainly merge +thousands of patches a day. + compnerd wrote: > I don't fully understand how this is any different from today. We have a > core set of developers with commit access. Others are encouraged to provide > patches via email (or may use phabricator depending on the reviewer). Once > reviewed and accepted, one of the core developers still commits the change. > I just see this as a process change. > > The person forks the repository on github, and creates a branch, and then a > PR. The PR is reviewed and once accepted, merged by one of the core > developers. It even implicitly handles authorship tracking which has > currently been done in an adhoc fashion via the commit message. Today we all commit to SVN, which is linear. In GitHub, we'll be committing to git. If we can have hooks forbidding merges, it'll remain linear, but then pull requests will be blocked. Additional hooks will need to be in place (please suggest all of them here and I'll update the doc). Comment at: docs/Proposals/GitHub.rst:222 @@ +221,3 @@ +10. Collect peoples GitHub account information, give them push access. Ideally +while still locking the GitHub repository somehow... +11. Switch SVN repository to read-only and allow pushes to the GitHub repository. compnerd wrote: > Giving permissions to only the LLVM "project" is sufficient. People can be > added to the LLVM "project" as collaborators and get access that way. This > is similar to how Apple is managing swift for comparison. That's what I meant but I will change the wording. Repository: rL LLVM https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r275791 - Revert "[test] Report error when inferior test processes exit with a non-zero code"
Author: labath
Date: Mon Jul 18 09:42:01 2016
New Revision: 275791
URL: http://llvm.org/viewvc/llvm-project?rev=275791&view=rev
Log:
Revert "[test] Report error when inferior test processes exit with a non-zero
code"
This reverts r275782.
The problem with the commit is that it reports an additional "exit (1)" error
for every file
containing a failing test, which is far more than I had intended to do. I'll
need to come up with
a more fine-grained way of achieving the result.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/dosep.py
lldb/trunk/packages/Python/lldbsuite/test/test_runner/process_control.py
Modified: lldb/trunk/packages/Python/lldbsuite/test/dosep.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dosep.py?rev=275791&r1=275790&r2=275791&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/dosep.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/dosep.py Mon Jul 18 09:42:01 2016
@@ -109,14 +109,13 @@ def report_test_failure(name, command, o
with output_lock:
if not (RESULTS_FORMATTER and RESULTS_FORMATTER.is_using_terminal()):
print(file=sys.stderr)
+print(output, file=sys.stderr)
if timeout:
timeout_str = " (TIMEOUT)"
else:
timeout_str = ""
print("[%s FAILED]%s" % (name, timeout_str), file=sys.stderr)
print("Command invoked: %s" % ' '.join(command), file=sys.stderr)
-print("Command stderr:\n", output[1], file=sys.stderr)
-print("Command stdout:\n", output[0], file=sys.stderr)
update_progress(name)
@@ -211,7 +210,7 @@ class DoTestProcessDriver(process_contro
# only stderr does.
report_test_pass(self.file_name, output[1])
else:
-report_test_failure(self.file_name, command, output, was_timeout)
+report_test_failure(self.file_name, command, output[1],
was_timeout)
# Save off the results for the caller.
self.results = (
Modified:
lldb/trunk/packages/Python/lldbsuite/test/test_runner/process_control.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/test_runner/process_control.py?rev=275791&r1=275790&r2=275791&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/test_runner/process_control.py
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/test_runner/process_control.py
Mon Jul 18 09:42:01 2016
@@ -246,25 +246,33 @@ class ProcessHelper(object):
def is_exceptional_exit(self, popen_status):
"""Returns whether the program exit status is exceptional.
-Returns whether the return code from a Popen process is exceptional.
+Returns whether the return code from a Popen process is exceptional
+(e.g. signals on POSIX systems).
+
+Derived classes should override this if they can detect exceptional
+program exit.
@return True if the given popen_status represents an exceptional
program exit; False otherwise.
"""
-return popen_status != 0
+return False
def exceptional_exit_details(self, popen_status):
"""Returns the normalized exceptional exit code and a description.
Given an exceptional exit code, returns the integral value of the
-exception and a description for the result.
+exception (e.g. signal number for POSIX) and a description (e.g.
+signal name on POSIX) for the result.
+
+Derived classes should override this if they can detect exceptional
+program exit.
-Derived classes can override this if they want to want custom
-exceptional exit code handling.
+It is fine to not implement this so long as is_exceptional_exit()
+always returns False.
@return (normalized exception code, symbolic exception description)
"""
-return (popen_status, "exit")
+raise Exception("exception_exit_details() called on unsupported class")
class UnixProcessHelper(ProcessHelper):
@@ -389,6 +397,9 @@ class UnixProcessHelper(ProcessHelper):
def soft_terminate_signals(self):
return [signal.SIGQUIT, signal.SIGTERM]
+def is_exceptional_exit(self, popen_status):
+return popen_status < 0
+
@classmethod
def _signal_names_by_number(cls):
return dict(
@@ -396,8 +407,6 @@ class UnixProcessHelper(ProcessHelper):
if v.startswith('SIG') and not v.startswith('SIG_'))
def exceptional_exit_details(self, popen_status):
-if popen_status >= 0:
-return (popen_status, "exit")
signo = -popen_status
signal_names_by_number = self._signal_names_by_number()
signal_name = signal_names_by_number.get(signo,
[Lldb-commits] [lldb] r275785 - [LLVM][MIPS] Revert support for FRE.
Author: nitesh.jain
Date: Mon Jul 18 07:37:44 2016
New Revision: 275785
URL: http://llvm.org/viewvc/llvm-project?rev=275785&view=rev
Log:
[LLVM][MIPS] Revert support for FRE.
Reviewers: jaydeep
Subscribers: bhushan, mohit.bhakkad, slthakur, llvm-commits
Modified:
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp
Modified:
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp?rev=275785&r1=275784&r2=275785&view=diff
==
---
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp
(original)
+++
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp
Mon Jul 18 07:37:44 2016
@@ -824,7 +824,8 @@ NativeRegisterContextLinux_mips64::ReadC
error = NativeRegisterContextLinux::ReadFPR();
}
-if (IsFR0() || IsFRE())
+// TODO: Add support for FRE
+if (IsFR0())
{
src = (uint8_t *)&m_fpr + 4 + (IsBigEndian * 4);
dst = (uint8_t *)&m_fpr + 8 + (IsBigEndian * 4);
@@ -851,7 +852,8 @@ NativeRegisterContextLinux_mips64::Write
uint32_t IsBigEndian = (byte_order == lldb::eByteOrderBig);
-if (IsFR0() || IsFRE())
+// TODO: Add support for FRE
+if (IsFR0())
{
src = (uint8_t *)&m_fpr + 8 + (IsBigEndian * 4);
dst = (uint8_t *)&m_fpr + 4 + (IsBigEndian * 4);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22404: [test] Report error when inferior test processes exit with a non-zero code
labath added a comment. I have now :) https://reviews.llvm.org/D22404 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22404: [test] Report error when inferior test processes exit with a non-zero code
This revision was automatically updated to reflect the committed changes.
Closed by commit rL275782: [test] Report error when inferior test processes
exit with a non-zero code (authored by labath).
Changed prior to commit:
https://reviews.llvm.org/D22404?vs=64115&id=64297#toc
https://reviews.llvm.org/D22404
Files:
lldb/trunk/packages/Python/lldbsuite/test/dosep.py
lldb/trunk/packages/Python/lldbsuite/test/test_runner/process_control.py
Index: lldb/trunk/packages/Python/lldbsuite/test/test_runner/process_control.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/test_runner/process_control.py
+++ lldb/trunk/packages/Python/lldbsuite/test/test_runner/process_control.py
@@ -246,33 +246,25 @@
def is_exceptional_exit(self, popen_status):
"""Returns whether the program exit status is exceptional.
-Returns whether the return code from a Popen process is exceptional
-(e.g. signals on POSIX systems).
-
-Derived classes should override this if they can detect exceptional
-program exit.
+Returns whether the return code from a Popen process is exceptional.
@return True if the given popen_status represents an exceptional
program exit; False otherwise.
"""
-return False
+return popen_status != 0
def exceptional_exit_details(self, popen_status):
"""Returns the normalized exceptional exit code and a description.
Given an exceptional exit code, returns the integral value of the
-exception (e.g. signal number for POSIX) and a description (e.g.
-signal name on POSIX) for the result.
-
-Derived classes should override this if they can detect exceptional
-program exit.
+exception and a description for the result.
-It is fine to not implement this so long as is_exceptional_exit()
-always returns False.
+Derived classes can override this if they want to want custom
+exceptional exit code handling.
@return (normalized exception code, symbolic exception description)
"""
-raise Exception("exception_exit_details() called on unsupported class")
+return (popen_status, "exit")
class UnixProcessHelper(ProcessHelper):
@@ -397,16 +389,15 @@
def soft_terminate_signals(self):
return [signal.SIGQUIT, signal.SIGTERM]
-def is_exceptional_exit(self, popen_status):
-return popen_status < 0
-
@classmethod
def _signal_names_by_number(cls):
return dict(
(k, v) for v, k in reversed(sorted(signal.__dict__.items()))
if v.startswith('SIG') and not v.startswith('SIG_'))
def exceptional_exit_details(self, popen_status):
+if popen_status >= 0:
+return (popen_status, "exit")
signo = -popen_status
signal_names_by_number = self._signal_names_by_number()
signal_name = signal_names_by_number.get(signo, "")
Index: lldb/trunk/packages/Python/lldbsuite/test/dosep.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/dosep.py
+++ lldb/trunk/packages/Python/lldbsuite/test/dosep.py
@@ -109,13 +109,14 @@
with output_lock:
if not (RESULTS_FORMATTER and RESULTS_FORMATTER.is_using_terminal()):
print(file=sys.stderr)
-print(output, file=sys.stderr)
if timeout:
timeout_str = " (TIMEOUT)"
else:
timeout_str = ""
print("[%s FAILED]%s" % (name, timeout_str), file=sys.stderr)
print("Command invoked: %s" % ' '.join(command), file=sys.stderr)
+print("Command stderr:\n", output[1], file=sys.stderr)
+print("Command stdout:\n", output[0], file=sys.stderr)
update_progress(name)
@@ -210,7 +211,7 @@
# only stderr does.
report_test_pass(self.file_name, output[1])
else:
-report_test_failure(self.file_name, command, output[1],
was_timeout)
+report_test_failure(self.file_name, command, output, was_timeout)
# Save off the results for the caller.
self.results = (
Index: lldb/trunk/packages/Python/lldbsuite/test/test_runner/process_control.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/test_runner/process_control.py
+++ lldb/trunk/packages/Python/lldbsuite/test/test_runner/process_control.py
@@ -246,33 +246,25 @@
def is_exceptional_exit(self, popen_status):
"""Returns whether the program exit status is exceptional.
-Returns whether the return code from a Popen process is exceptional
-(e.g. signals on POSIX systems).
-
-Derived classes should override this if they can detect exceptional
-program exit.
+Returns whether the return
[Lldb-commits] [lldb] r275782 - [test] Report error when inferior test processes exit with a non-zero code
Author: labath
Date: Mon Jul 18 06:27:19 2016
New Revision: 275782
URL: http://llvm.org/viewvc/llvm-project?rev=275782&view=rev
Log:
[test] Report error when inferior test processes exit with a non-zero code
Summary:
We've run into this problem when the test errored out so early (because it
could not connect to
the remote device), that the code in D20193 did not catch the error. This
resulted in the test
suite reporting success with 0 tests being run.
This patch makes sure that any non-zero exit code from the inferior process
gets reported as an
error. Basically I expand the concept of "exceptional exits", which was
previously being used for
signals to cover these cases as well.
Reviewers: tfiala, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D22404
Modified:
lldb/trunk/packages/Python/lldbsuite/test/dosep.py
lldb/trunk/packages/Python/lldbsuite/test/test_runner/process_control.py
Modified: lldb/trunk/packages/Python/lldbsuite/test/dosep.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dosep.py?rev=275782&r1=275781&r2=275782&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/dosep.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/dosep.py Mon Jul 18 06:27:19 2016
@@ -109,13 +109,14 @@ def report_test_failure(name, command, o
with output_lock:
if not (RESULTS_FORMATTER and RESULTS_FORMATTER.is_using_terminal()):
print(file=sys.stderr)
-print(output, file=sys.stderr)
if timeout:
timeout_str = " (TIMEOUT)"
else:
timeout_str = ""
print("[%s FAILED]%s" % (name, timeout_str), file=sys.stderr)
print("Command invoked: %s" % ' '.join(command), file=sys.stderr)
+print("Command stderr:\n", output[1], file=sys.stderr)
+print("Command stdout:\n", output[0], file=sys.stderr)
update_progress(name)
@@ -210,7 +211,7 @@ class DoTestProcessDriver(process_contro
# only stderr does.
report_test_pass(self.file_name, output[1])
else:
-report_test_failure(self.file_name, command, output[1],
was_timeout)
+report_test_failure(self.file_name, command, output, was_timeout)
# Save off the results for the caller.
self.results = (
Modified:
lldb/trunk/packages/Python/lldbsuite/test/test_runner/process_control.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/test_runner/process_control.py?rev=275782&r1=275781&r2=275782&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/test_runner/process_control.py
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/test_runner/process_control.py
Mon Jul 18 06:27:19 2016
@@ -246,33 +246,25 @@ class ProcessHelper(object):
def is_exceptional_exit(self, popen_status):
"""Returns whether the program exit status is exceptional.
-Returns whether the return code from a Popen process is exceptional
-(e.g. signals on POSIX systems).
-
-Derived classes should override this if they can detect exceptional
-program exit.
+Returns whether the return code from a Popen process is exceptional.
@return True if the given popen_status represents an exceptional
program exit; False otherwise.
"""
-return False
+return popen_status != 0
def exceptional_exit_details(self, popen_status):
"""Returns the normalized exceptional exit code and a description.
Given an exceptional exit code, returns the integral value of the
-exception (e.g. signal number for POSIX) and a description (e.g.
-signal name on POSIX) for the result.
-
-Derived classes should override this if they can detect exceptional
-program exit.
+exception and a description for the result.
-It is fine to not implement this so long as is_exceptional_exit()
-always returns False.
+Derived classes can override this if they want to want custom
+exceptional exit code handling.
@return (normalized exception code, symbolic exception description)
"""
-raise Exception("exception_exit_details() called on unsupported class")
+return (popen_status, "exit")
class UnixProcessHelper(ProcessHelper):
@@ -397,9 +389,6 @@ class UnixProcessHelper(ProcessHelper):
def soft_terminate_signals(self):
return [signal.SIGQUIT, signal.SIGTERM]
-def is_exceptional_exit(self, popen_status):
-return popen_status < 0
-
@classmethod
def _signal_names_by_number(cls):
return dict(
@@ -407,6 +396,8 @@ class UnixProcessHelper(ProcessHelper):
if v.startswith(
[Lldb-commits] [PATCH] D22457: Unify process launching code on linux
labath created this revision.
labath added a reviewer: tberghammer.
labath added a subscriber: lldb-commits.
Herald added subscribers: srhines, danalbert, tberghammer.
We've had two copies of code for launching processes:
- one in NativeProcessLinux, used for launching debugged processes
- one in ProcessLauncherAndroid, used on android for launching all other kinds
of processes
These have over time acquired support for various launch options, but neither
supported all of
them. I now replace them with a single implementation ProcessLauncherLinux,
which supports all
the options the individual versions supported and set it to be used to launch
all processes on
linux.
This also works around the ETXTBSY issue on android when the process is started
from the platform
instance, as that used to go through the version which did not contain the
workaround.
https://reviews.llvm.org/D22457
Files:
include/lldb/Host/android/ProcessLauncherAndroid.h
include/lldb/Host/linux/ProcessLauncherLinux.h
source/Host/CMakeLists.txt
source/Host/android/ProcessLauncherAndroid.cpp
source/Host/common/Host.cpp
source/Host/linux/ProcessLauncherLinux.cpp
source/Plugins/Process/Linux/NativeProcessLinux.cpp
source/Plugins/Process/Linux/NativeProcessLinux.h
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
Index: source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -203,6 +203,15 @@
if (!m_process_launch_info.GetArguments ().GetArgumentCount ())
return Error ("%s: no process command line specified to launch", __FUNCTION__);
+const bool should_forward_stdio = m_process_launch_info.GetFileActionForFD(STDIN_FILENO) == nullptr ||
+ m_process_launch_info.GetFileActionForFD(STDOUT_FILENO) == nullptr ||
+ m_process_launch_info.GetFileActionForFD(STDERR_FILENO) == nullptr;
+m_process_launch_info.SetLaunchInSeparateProcessGroup(true);
+m_process_launch_info.GetFlags().Set(eLaunchFlagDebug);
+
+const bool default_to_use_pty = true;
+m_process_launch_info.FinalizeFileActions(nullptr, default_to_use_pty);
+
Error error;
{
std::lock_guard guard(m_debugged_process_mutex);
@@ -226,11 +235,7 @@
// file actions non-null
// process launch -i/e/o will also make these file actions non-null
// nullptr means that the traffic is expected to flow over gdb-remote protocol
-if (
-m_process_launch_info.GetFileActionForFD(STDIN_FILENO) == nullptr ||
-m_process_launch_info.GetFileActionForFD(STDOUT_FILENO) == nullptr ||
-m_process_launch_info.GetFileActionForFD(STDERR_FILENO) == nullptr
-)
+if (should_forward_stdio)
{
// nullptr means it's not redirected to file or pty (in case of LLGS local)
// at least one of stdio will be transferred pty<->gdb-remote
@@ -998,14 +1003,6 @@
if (! m_stdio_communication.IsConnected())
return;
-// llgs local-process debugging may specify PTY paths, which will make these
-// file actions non-null
-// process launch -e/o will also make these file actions non-null
-// nullptr means that the traffic is expected to flow over gdb-remote protocol
-if ( m_process_launch_info.GetFileActionForFD(STDOUT_FILENO) &&
- m_process_launch_info.GetFileActionForFD(STDERR_FILENO))
-return;
-
Error error;
lldbassert(! m_stdio_handle_up);
m_stdio_handle_up = m_mainloop.RegisterReadObject(
Index: source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
===
--- source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
+++ source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
@@ -884,8 +884,8 @@
FileAction file_action;
std::string path;
packet.GetHexByteString(path);
-const bool read = false;
-const bool write = true;
+const bool read = true;
+const bool write = false;
if (file_action.Open(STDIN_FILENO, FileSpec{path, false}, read, write))
{
m_process_launch_info.AppendFileAction(file_action);
@@ -901,8 +901,8 @@
FileAction file_action;
std::string path;
packet.GetHexByteString(path);
-const bool read = true;
-const bool write = false;
+const bool read = false;
+const bool write = true;
if (file_action.Open(STDOUT_FILENO, FileSpec{path, false}, read, write))
{
m_process_launch_info.AppendFileAction(file_action);
@@ -918,8 +918,8 @@
FileAction file_action;
std::string path;
packet.GetHexByteString(path);
-c
[Lldb-commits] [lldb] r275778 - Implement GetMemoryRegions() for Windows Minidumps and live processes.
Author: hhellyer
Date: Mon Jul 18 03:25:59 2016
New Revision: 275778
URL: http://llvm.org/viewvc/llvm-project?rev=275778&view=rev
Log:
Implement GetMemoryRegions() for Windows Minidumps and live processes.
Summary:
This patch fills in the implementation of GetMemoryRegions() on the Windows
live process and minidump implementations of lldb_private::Process
(ProcessWindowsLive::GetMemoryRegionInfo and
ProcessWinMiniDump::Impl::GetMemoryRegionInfo.) The GetMemoryRegions API was
added under: http://reviews.llvm.org/D20565
The existing Windows implementations didn’t fill in the start and end addresses
within MemoryRegionInfo. This patch fixes that and adds support for the new
mapped flag on MemoryRegionInfo that says whether a memory range is mapped into
the process address space or not.
The behaviour of both live and core implementations should match the behaviour
documented on Process::GetMemoryRegionInfo (in Process.h) which in turn should
match the behaviour of the qMemoryRegionInfo query documented in
lldb-gdb-remote.txt.
Reviewers: clayborg, amccarth
Subscribers: amccarth, lldb-commits
Differential Revision: https://reviews.llvm.org/D22352
Modified:
lldb/trunk/source/Plugins/Process/Windows/Live/ProcessWindowsLive.cpp
lldb/trunk/source/Plugins/Process/Windows/MiniDump/ProcessWinMiniDump.cpp
Modified: lldb/trunk/source/Plugins/Process/Windows/Live/ProcessWindowsLive.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Windows/Live/ProcessWindowsLive.cpp?rev=275778&r1=275777&r2=275778&view=diff
==
--- lldb/trunk/source/Plugins/Process/Windows/Live/ProcessWindowsLive.cpp
(original)
+++ lldb/trunk/source/Plugins/Process/Windows/Live/ProcessWindowsLive.cpp Mon
Jul 18 03:25:59 2016
@@ -748,6 +748,7 @@ ProcessWindowsLive::GetMemoryRegionInfo(
{
Error error;
llvm::sys::ScopedLock lock(m_mutex);
+info.Clear();
if (!m_session_data)
{
@@ -755,7 +756,6 @@ ProcessWindowsLive::GetMemoryRegionInfo(
WINERR_IFALL(WINDOWS_LOG_MEMORY, error.AsCString());
return error;
}
-
HostProcess process = m_session_data->m_debugger->GetProcess();
lldb::process_t handle = process.GetNativeProcess().GetSystemHandle();
if (handle == nullptr || handle == LLDB_INVALID_PROCESS)
@@ -772,22 +772,67 @@ ProcessWindowsLive::GetMemoryRegionInfo(
SIZE_T result = ::VirtualQueryEx(handle, addr, &mem_info,
sizeof(mem_info));
if (result == 0)
{
-error.SetError(::GetLastError(), eErrorTypeWin32);
-WINERR_IFALL(WINDOWS_LOG_MEMORY,
- "VirtualQueryEx returned error %u while getting memory
region info for address 0x%I64x",
- error.GetError(), vm_addr);
-return error;
+if (::GetLastError() == ERROR_INVALID_PARAMETER)
+{
+// ERROR_INVALID_PARAMETER is returned if VirtualQueryEx is called
with an address
+// past the highest accessible address. We should return a range
from the vm_addr
+// to LLDB_INVALID_ADDRESS
+info.GetRange().SetRangeBase(vm_addr);
+info.GetRange().SetRangeEnd(LLDB_INVALID_ADDRESS);
+info.SetReadable(MemoryRegionInfo::eNo);
+info.SetExecutable(MemoryRegionInfo::eNo);
+info.SetWritable(MemoryRegionInfo::eNo);
+info.SetMapped(MemoryRegionInfo::eNo);
+return error;
+}
+else
+{
+error.SetError(::GetLastError(), eErrorTypeWin32);
+WINERR_IFALL(WINDOWS_LOG_MEMORY,
+"VirtualQueryEx returned error %u while getting memory
region info for address 0x%I64x",
+error.GetError(), vm_addr);
+return error;
+}
+}
+
+// Protect bits are only valid for MEM_COMMIT regions.
+if (mem_info.State == MEM_COMMIT) {
+const bool readable = IsPageReadable(mem_info.Protect);
+const bool executable = IsPageExecutable(mem_info.Protect);
+const bool writable = IsPageWritable(mem_info.Protect);
+info.SetReadable(readable ? MemoryRegionInfo::eYes :
MemoryRegionInfo::eNo);
+info.SetExecutable(executable ? MemoryRegionInfo::eYes :
MemoryRegionInfo::eNo);
+info.SetWritable(writable ? MemoryRegionInfo::eYes :
MemoryRegionInfo::eNo);
+}
+else
+{
+info.SetReadable(MemoryRegionInfo::eNo);
+info.SetExecutable(MemoryRegionInfo::eNo);
+info.SetWritable(MemoryRegionInfo::eNo);
+}
+
+// AllocationBase is defined for MEM_COMMIT and MEM_RESERVE but not
MEM_FREE.
+if (mem_info.State != MEM_FREE) {
+
info.GetRange().SetRangeBase(reinterpret_cast(mem_info.AllocationBase));
+
info.GetRange().SetRangeEnd(reinterpret_cast(mem_info.BaseAddress) +
mem_info.RegionSize);
+info.SetMapped(MemoryRegionInfo::eYes);
+}
+else
+{
+// In
Re: [Lldb-commits] [PATCH] D22213: [test] Fix category-based skipping
tfiala added a comment. > ! In https://reviews.llvm.org/D22213#481728, @labath wrote: > I don't remember seeing any changes here so it's quite possible it never > worked in the first place, but I have no idea what could be different about > my setup. I'll have to have a look at it. Thanks for pointing it out! Repository: rL LLVM https://reviews.llvm.org/D22213 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
