[Lldb-commits] [lldb] r297626 - Delete dead code. NFC
Author: jroelofs
Date: Mon Mar 13 10:25:01 2017
New Revision: 297626
URL: http://llvm.org/viewvc/llvm-project?rev=297626&view=rev
Log:
Delete dead code. NFC
Also has the side-effect of fixing the build on systems with glibc < 2.12
https://reviews.llvm.org/D30844
Modified:
lldb/trunk/include/lldb/Host/linux/HostThreadLinux.h
lldb/trunk/source/Host/linux/HostThreadLinux.cpp
Modified: lldb/trunk/include/lldb/Host/linux/HostThreadLinux.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/linux/HostThreadLinux.h?rev=297626&r1=297625&r2=297626&view=diff
==
--- lldb/trunk/include/lldb/Host/linux/HostThreadLinux.h (original)
+++ lldb/trunk/include/lldb/Host/linux/HostThreadLinux.h Mon Mar 13 10:25:01
2017
@@ -22,7 +22,6 @@ public:
HostThreadLinux();
HostThreadLinux(lldb::thread_t thread);
- static void SetName(lldb::thread_t thread, llvm::StringRef name);
static void GetName(lldb::thread_t thread, llvm::SmallVectorImpl
&name);
};
}
Modified: lldb/trunk/source/Host/linux/HostThreadLinux.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/linux/HostThreadLinux.cpp?rev=297626&r1=297625&r2=297626&view=diff
==
--- lldb/trunk/source/Host/linux/HostThreadLinux.cpp (original)
+++ lldb/trunk/source/Host/linux/HostThreadLinux.cpp Mon Mar 13 10:25:01 2017
@@ -13,8 +13,6 @@
#include "llvm/ADT/SmallVector.h"
-#include
-
using namespace lldb_private;
HostThreadLinux::HostThreadLinux() : HostThreadPosix() {}
@@ -22,15 +20,6 @@ HostThreadLinux::HostThreadLinux() : Hos
HostThreadLinux::HostThreadLinux(lldb::thread_t thread)
: HostThreadPosix(thread) {}
-void HostThreadLinux::SetName(lldb::thread_t thread, llvm::StringRef name) {
-#if (defined(__GLIBC__) && defined(_GNU_SOURCE)) || defined(__ANDROID__)
- ::pthread_setname_np(thread, name.data());
-#else
- (void)thread;
- (void)name;
-#endif
-}
-
void HostThreadLinux::GetName(lldb::thread_t thread,
llvm::SmallVectorImpl &name) {
// Read /proc/$TID/comm file.
___
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
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!
On 7/19/16 8:55 AM, Robinson, Paul wrote: 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 Hear hear. The schemes to handle this that I'm aware of do look more like pull requests. You submit your change to the pre-qualification queue. If it rebases cleanly and passes pre-qual, your change becomes the new HEAD. If it doesn't rebase cleanly or fails pre-qual, your change gets bounced. Reminds me a bit of a blockchain: longest validated chain of commits wins. Jon A pull-request-like model also helps avoid the rebase-build-test-push(fail) loop that you can get into with a very active git-based project. This is a mechanical task best suited to automation rather than wasting valuable developer time on it. But I suspect GitHub does not have anything like this OOB so it would be an enhancement for a later time. --paulr P.S. At Sony we are building a system with a "staging" step but it's not for our own work... more of a "flood control" dam. :-) -- Jon Roelofs jonat...@codesourcery.com CodeSourcery / Mentor Embedded ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
