Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
jlebar added a subscriber: jlebar. jlebar added a comment. I'm sure you all have thought about this more than I have, and I apologize if this has been brought up before because I haven't been following the thread closely. But I am not convinced by this document that using subrepositories beats using a single git repo. I see two reasons here for using subrepos as opposed to one big repository. 1. Subrepos mirror our current scheme. 2. Subrepos let people check out only the bits of llvm that they want. I don't find either of these particularly compelling, compared to the advantages of one-big-repo (discussed below). Taking them in turn: 1. Although subrepos would mirror our current scheme, it's going to be different *enough* that existing tools are going to have to change either way. In particular, the svn view of the master repository is not going to be useful for anything. I tried `svn checkout https://github.com/chapuni/llvm-project-submodule`, and the result was essentially an empty repository. 2. It's true that subrepos let people check out only the bits that they want. But disk space and bandwidth are very cheap today, and LLVM is not as large as one might think. My copy of https://github.com/llvm-project/llvm-project, which includes *everything* is 2.5G, whereas my copy of just llvm is 626M. Given that a release build of llvm and clang is ~3.5G, a 2.5G source checkout doesn't seem at all unreasonable to me. If it's really problematic, you can do a shallow checkout, which would take the contains-everything repo from 2.5G to 1.3G. Moreover if it's *really* a problem, you can mirror the subdir of llvm that you care about. Maybe the LLVM project could maintain said mirrors for some of the small subrepos that are often used independently. So what's the advantage of using one big repository? The simple answer is: Have you ever *tried* using git submodules? :) Submodules make everything more complicated. Here's an example that I hope proves the point. Suppose you want to commit your current work and switch to a new clean branch off head. You make some changes there, then come back to your current work. And let's assume that all of your changes are to clang only. # Commit current work, switch to a clean branch off head, then switch back. # One big repo: $ git commit # on old-branch $ git fetch $ git checkout -b new-branch origin/master # Hack hack hack... $ git commit $ git checkout old-branch # Submodules, attempt 1: $ cd clang $ git commit # on old-branch $ git fetch $ git checkout -b new-branch origin/master # Also have to update llvm... $ cd ../llvm $ git fetch $ git checkout origin/master $ cd ../clang # Hack hack hack $ git commit # Now we're ready to switch back to old-branch, but...it's not going to work. # When we committed our old branch, we didn't save the state of our llvm # checkout. So in particular we don't know which revision to roll it back to. # Let's try again. # Submodules, attempt 2: $ cd clang $ git commit # on old-branch $ cd .. $ git checkout -b old-branch # in master repo $ git commit # Now we have two branches called "old-branch": One in the master repo, and one # in the clang submodules. Now let's fetch head. $ git fetch # in master repo $ git checkout -b new-branch origin/master $ git submodule update $ cd clang $ git checkout -b new-branch # Hack hack hack $ git commit # in submodule $ cd .. $ git commit # in master repo # Now we're ready to switch back. $ git checkout old-branch # in master repo $ git submodule update For those keeping track at home, this is 5 git commands with the big repo, and 15 commands (11 git commands) in the submodules world. Above we assumed that all of our changes were only to clang. If we're making changes to both llvm and clang (say), the one-big-repo workflow remains identical, but the submodules workflow becomes even more complicated. I'm sure people who are better at git than I can golf the above commands, but I'll suggest that I'm an above-average git user, so this is probably a lower-than-average estimate for the number of git commands (particularly `git help` :). git is hard enough as-is; using submodules like this is asking a lot. Similarly, I'm sure much of this can be scripted, but...seriously? :) Sorry for the wall of text. tl;dr: One big repo doesn't actually cost that much, and that cost is dwarfed by the cost to humans of using submodules as proposed. 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!
jlebar added a comment. FYI after talking to Chandler, I'm going to write up a separate proposal for the one-repository thing and send it to the list tomorrow. The suggestion was that this phabricator thread isn't the right place to have this discussion. 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!
jlebar added a comment. In https://reviews.llvm.org/D22463#489461, @rengolin wrote: > You will not be required to use submodules at all, as we'll all use the > individual projects, like we have always been. I don't understand why people > keep going back to it. There is a key use case that is not supported by the current setup. This is something that I -- and basically anyone who works on an llvm project other than llvm itself -- do every day. It will be supported with submodules, but badly. It is not supported at all today, and it will not be supported at all in the proposed world if I don't use submodules. Maybe the people who keep coming back to this have not explained this use-case clearly, so let me try. The use-case is: Maintaining a branch which contains changes to clang (or your favorite subproject) and also is locked to a specific revision of llvm. That is, I can check out branch A or branch B of my changes to clang, and it automatically checks out a corresponding revision of llvm that is tied to the branch. Again, we can make this work with submodules, but it's a giant pain, see my earlier comment. It works with zero effort if we have a monolithic repository. This would be 'uge for anyone who works on clang (or any other subproject that's not llvm itself) and uses branches. > Having a single repository was part of the original proposal for years, and > every time it was shot down as impractical. I've read as many of these as I can find in the past few hours, and every argument I have found is, in my evaluation, very likely overblown or incorrect. There is strong evidence for this, in the single git repository that already exists (and includes the test-suite, so is much larger than what I propose), and also in the fact that adding everything to a single git repository will not more than ~double the size of the llvm git repo. (I'll have better numbers tomorrow, don't quote me on that just yet.) Moreover, the current setup of unrelated git repos can be *exactly duplicated* by making sparse checkouts of the monolithic repository. You can clone the big repo and then check out only the directories you want (so it's like the others never existed, beyond their presence in your .git packfiles). Or if you want to be able to check out different revisions of (say) clang and llvm, you can do that too: Clone the big repo and make two shallow working copies, one for llvm and the other for clang. You can even place the clang working copy in tools/clang of the llvm working copy, so it functions identically to the current setup in almost every way. The critical point is that it's trivial to use sparse checkouts to make the monolithic repository behave identically to separate repos. But it is impossible, as far as I'm aware, to make separate repos behave like a monolithic repository. So the monolithic repository is strictly more powerful. > Indeed, this is not the place for such discussion, but unless you can finish > the discussion thus week, I suggest you make you point clear in the survey > instead of delaying the process. The e-mail you sent out two days ago said two weeks. Can you give me a bit more than three days? > I'm not pushing for *my* solution. Thus *has* been discussed already to > exhaustion. The current agreement was that we'd do a survey on the proposal, > and that's what we need to do. Anything else will just send us back to square > one and I seriously don't have the stamina to keep going round in circles. > > Ie. Please, try to be considerate. I am very grateful for the work that you're doing here. I have participated in efforts very similar to this one in the past, and I appreciate how difficult and taxing they can be, and also how frustrating it can be to be see perfect be made the enemy of the good. In fact I quit my last job in part over friction created by a botched move to git. But. I would ask you to please give me a few days to work with the community to dig in to this specific question. If I am right, it will be a boon for all of us every time we type a command that starts with "git". And if I'm wrong, I'll buy you a well-deserved beer or three, and we'll forget it and move on. Does that sound agreeable to you? 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!
jlebar added a comment. Hi, Renato. Just to explain why I'm going to go forward with this RFC about a monolithic repository: From speaking with some top contributors on IRC, I have heard that they feel that the discussion of whether to move to git has been conflated with the discussion of how the git repository should be set up. So there is a sizable set of important individuals who don't feel that this question has been considered sufficiently. I would love not to alienate you by asking this question, but I understand if I already have. If so, I sincerely apologize. 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!
jlebar added a comment. In https://reviews.llvm.org/D22463#494568, @vladisld wrote: > Have the alternatives to sub-modules and monolithic repository been discussed > ? Hi, Vlad. Please see the ongoing thread in llvm-dev, entitled "[RFC] One or many git repositories?". Tools such as git-repo, have been discussed briefly. I think the general feeling is that most of us (myself included) would rather not learn a new tool if there's a simpler alternative, such as a vanilla git workflow. But if you would like to discuss more, that thread is the right place. -Justin 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!
jlebar added a comment. In https://reviews.llvm.org/D22463#495211, @vladisld wrote: > In https://reviews.llvm.org/D22463#494828, @jlebar wrote: > > > I think the general feeling is that most of us (myself included) would > > rather not learn a new tool if there's a simpler >alternative, such as a > > vanilla git workflow. > > > Generally you're right, however learning how to use git-repo is much simpler > than managing the intricacies of git sub-modules (and Google's experience > with Android is a clear example of it). This is IMHO of cause. Just to be clear, since it sounds like you haven't been following the llvm-dev discussion -- the alternative to git-repo is *not* submodules. I agree that submodules are awful. The alternative is a monolithic repository (monorepo) that contains, as a single git repository, the full history of all llvm subprojects. Similar to https://github.com/llvm-project/llvm-project. 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] r282822 - Move UTF functions into namespace llvm.
Author: jlebar
Date: Thu Sep 29 19:38:45 2016
New Revision: 282822
URL: http://llvm.org/viewvc/llvm-project?rev=282822&view=rev
Log:
Move UTF functions into namespace llvm.
Summary:
This lets people link against LLVM and their own version of the UTF
library.
I determined this only affects llvm, clang, lld, and lldb by running
$ git grep -wl 'UTF[0-9]\+\|\bConvertUTF\bisLegalUTF\|getNumBytesFor' | cut -f
1 -d '/' | sort | uniq
clang
lld
lldb
llvm
Tested with
ninja lldb
ninja check-clang check-llvm check-lld
(ninja check-lldb doesn't complete for me with or without this patch.)
Reviewers: rnk
Subscribers: klimek, beanz, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D24996
Modified:
lldb/trunk/source/DataFormatters/StringPrinter.cpp
lldb/trunk/source/Plugins/Process/minidump/MinidumpTypes.cpp
Modified: lldb/trunk/source/DataFormatters/StringPrinter.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/DataFormatters/StringPrinter.cpp?rev=282822&r1=282821&r2=282822&view=diff
==
--- lldb/trunk/source/DataFormatters/StringPrinter.cpp (original)
+++ lldb/trunk/source/DataFormatters/StringPrinter.cpp Thu Sep 29 19:38:45 2016
@@ -133,7 +133,7 @@ GetPrintableImpl retval{nullptr};
- unsigned utf8_encoded_len = getNumBytesForUTF8(*buffer);
+ unsigned utf8_encoded_len = llvm::getNumBytesForUTF8(*buffer);
if (1 + buffer_end - buffer < utf8_encoded_len) {
// I don't have enough bytes - print whatever I have left
@@ -266,9 +266,10 @@ StringPrinter::GetDefaultEscapingHelper(
// use this call if you already have an LLDB-side buffer for the data
template
static bool DumpUTFBufferToStream(
-ConversionResult (*ConvertFunction)(const SourceDataType **,
-const SourceDataType *, UTF8 **, UTF8
*,
-ConversionFlags),
+llvm::ConversionResult (*ConvertFunction)(const SourceDataType **,
+ const SourceDataType *,
+ llvm::UTF8 **, llvm::UTF8 *,
+ llvm::ConversionFlags),
const StringPrinter::ReadBufferAndDumpToStreamOptions &dump_options) {
Stream &stream(*dump_options.GetStream());
if (dump_options.GetPrefixToken() != 0)
@@ -303,30 +304,29 @@ static bool DumpUTFBufferToStream(
}
lldb::DataBufferSP utf8_data_buffer_sp;
-UTF8 *utf8_data_ptr = nullptr;
-UTF8 *utf8_data_end_ptr = nullptr;
+llvm::UTF8 *utf8_data_ptr = nullptr;
+llvm::UTF8 *utf8_data_end_ptr = nullptr;
if (ConvertFunction) {
utf8_data_buffer_sp.reset(new DataBufferHeap(4 * bufferSPSize, 0));
- utf8_data_ptr = (UTF8 *)utf8_data_buffer_sp->GetBytes();
+ utf8_data_ptr = (llvm::UTF8 *)utf8_data_buffer_sp->GetBytes();
utf8_data_end_ptr = utf8_data_ptr + utf8_data_buffer_sp->GetByteSize();
ConvertFunction(&data_ptr, data_end_ptr, &utf8_data_ptr,
- utf8_data_end_ptr, lenientConversion);
+ utf8_data_end_ptr, llvm::lenientConversion);
if (false == zero_is_terminator)
utf8_data_end_ptr = utf8_data_ptr;
+ // needed because the ConvertFunction will change the value of the
+ // data_ptr.
utf8_data_ptr =
- (UTF8 *)utf8_data_buffer_sp->GetBytes(); // needed because the
- // ConvertFunction will
- // change the value of the
- // data_ptr
+ (llvm::UTF8 *)utf8_data_buffer_sp->GetBytes();
} else {
// just copy the pointers - the cast is necessary to make the compiler
// happy
// but this should only happen if we are reading UTF8 data
- utf8_data_ptr =
- const_cast(reinterpret_cast(data_ptr));
- utf8_data_end_ptr =
- const_cast(reinterpret_cast(data_end_ptr));
+ utf8_data_ptr = const_cast(
+ reinterpret_cast(data_ptr));
+ utf8_data_end_ptr = const_cast(
+ reinterpret_cast(data_end_ptr));
}
const bool escape_non_printables = dump_options.GetEscapeNonPrintables();
@@ -512,9 +512,10 @@ bool StringPrinter::ReadStringAndDumpToS
template
static bool ReadUTFBufferAndDumpToStream(
const StringPrinter::ReadStringAndDumpToStreamOptions &options,
-ConversionResult (*ConvertFunction)(const SourceDataType **,
-const SourceDataType *, UTF8 **, UTF8
*,
-ConversionFlags)) {
+llvm::ConversionResult (*ConvertFunction)(const SourceDataType **,
+ const SourceDataType *,
+ llvm::UTF8 **, llvm::UTF8 *,
+ llv
[Lldb-commits] [PATCH] D15684: Add note about the "thread until" command to the llvm-gdb cheatsheet.
jlebar created this revision. jlebar added a reviewer: brucem. jlebar added a subscriber: lldb-commits. http://reviews.llvm.org/D15684 Files: www/lldb-gdb.html Index: www/lldb-gdb.html === --- www/lldb-gdb.html +++ www/lldb-gdb.html @@ -307,6 +307,15 @@ Stop hook #1 added. +Run until we hit line 12 or control leaves the current function. + + +(gdb) until 12 + + +(lldb) thread until 12 + + Index: www/lldb-gdb.html === --- www/lldb-gdb.html +++ www/lldb-gdb.html @@ -307,6 +307,15 @@ Stop hook #1 added. +Run until we hit line 12 or control leaves the current function. + + +(gdb) until 12 + + +(lldb) thread until 12 + + ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15684: Add note about the "thread until" command to the llvm-gdb cheatsheet.
jlebar added a comment. Thank you for the review! http://reviews.llvm.org/D15684 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15684: Add note about the "thread until" command to the llvm-gdb cheatsheet.
jlebar added a comment. I just got commit access yesterday, will check in. http://reviews.llvm.org/D15684 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r257189 - Add note about the "thread until" command to the llvm-gdb cheatsheet.
Author: jlebar Date: Fri Jan 8 12:56:18 2016 New Revision: 257189 URL: http://llvm.org/viewvc/llvm-project?rev=257189&view=rev Log: Add note about the "thread until" command to the llvm-gdb cheatsheet. Differential Revision: http://reviews.llvm.org/D15684 Modified: lldb/trunk/www/lldb-gdb.html Modified: lldb/trunk/www/lldb-gdb.html URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/www/lldb-gdb.html?rev=257189&r1=257188&r2=257189&view=diff == --- lldb/trunk/www/lldb-gdb.html (original) +++ lldb/trunk/www/lldb-gdb.html Fri Jan 8 12:56:18 2016 @@ -307,6 +307,15 @@ Stop hook #1 added. +Run until we hit line 12 or control leaves the current function. + + +(gdb) until 12 + + +(lldb) thread until 12 + + ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15684: Add note about the "thread until" command to the llvm-gdb cheatsheet.
This revision was automatically updated to reflect the committed changes. Closed by commit rL257189: Add note about the "thread until" command to the llvm-gdb cheatsheet. (authored by jlebar). Changed prior to commit: http://reviews.llvm.org/D15684?vs=43346&id=44340#toc Repository: rL LLVM http://reviews.llvm.org/D15684 Files: lldb/trunk/www/lldb-gdb.html Index: lldb/trunk/www/lldb-gdb.html === --- lldb/trunk/www/lldb-gdb.html +++ lldb/trunk/www/lldb-gdb.html @@ -307,6 +307,15 @@ Stop hook #1 added. +Run until we hit line 12 or control leaves the current function. + + +(gdb) until 12 + + +(lldb) thread until 12 + + Index: lldb/trunk/www/lldb-gdb.html === --- lldb/trunk/www/lldb-gdb.html +++ lldb/trunk/www/lldb-gdb.html @@ -307,6 +307,15 @@ Stop hook #1 added. +Run until we hit line 12 or control leaves the current function. + + +(gdb) until 12 + + +(lldb) thread until 12 + + ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lld] [lldb] [clang-tools-extra] [clang] [libcxx] [libc] [flang] [llvm] [compiler-rt] [NVPTX] Add support for -march=native in standalone NVPTX (PR #79373)
jlebar wrote: > This method of compilation is not like CUDA, so we can't target all the GPUs > at the same time. Can you clarify for me -- what are you compiling where it's impossible to target multiple GPUs in the binary? I'm confused because Art is understanding that it's not CUDA, but we're modifying the CUDA driver here? https://github.com/llvm/llvm-project/pull/79373 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lld] [lldb] [libcxx] [compiler-rt] [clang-tools-extra] [llvm] [libc] [clang] [flang] [NVPTX] Add support for -march=native in standalone NVPTX (PR #79373)
jlebar wrote: I...think I understand. Is the output of this compilation step a cubin, then? https://github.com/llvm/llvm-project/pull/79373 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [flang] [libc] [compiler-rt] [clang] [clang-tools-extra] [llvm] [libcxx] [lld] [lldb] [NVPTX] Add support for -march=native in standalone NVPTX (PR #79373)
jlebar wrote: Got it, okay, thanks. Since this change only applies to `--target=nvptx64-nvidia-cuda`, fine by me. Thanks for putting up with our scrutiny. :) https://github.com/llvm/llvm-project/pull/79373 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
