[lldb-dev] win64 "patch"

[Carlo Kok via lldb-dev]

Seems win64 almost works fine out of the box. 1 minor thing is needed:


diff --git 
a/source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp 
b/source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp

index 103cff4..4b37c3f 100644
--- 
a/source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp
+++ 
b/source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp

@@ -136,6 +136,8 @@ RegisterInfo g_register_infos[] = {
  nullptr},
 };

+static size_t k_num_register_infos = 
llvm::array_lengthof(g_register_infos);

+
 // Array of lldb register numbers used to define the set of all 
General Purpose Registers
 uint32_t g_gpr_reg_indices[] = {eRegisterIndexRax, eRegisterIndexRbx, 
 eRegisterIndexRcx, eRegisterIndexRdx,
 eRegisterIndexRdi, eRegisterIndexRsi, 
 eRegisterIndexR8,  eRegisterIndexR9,

@@ -169,7 +171,9 @@ RegisterContextWindows_x64::GetRegisterCount()
 const RegisterInfo *
 RegisterContextWindows_x64::GetRegisterInfoAtIndex(size_t reg)
 {
-return &g_register_infos[reg];
+   if (reg < k_num_register_infos)
+   return &g_register_infos[reg];
+   return NULL;
 }

 size_t


The unwind logic asks for the "return address register" which doesn't 
exist; returns -1 and goes out of the bounds for g_register_infos.


--
Carlo Kok
RemObjects Software
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Inquiry regarding AddOneMoreFrame function in UnWindLLDB

[Ravitheja Addepally via lldb-dev]

Hello,
 This is happening in TestPrintStackTraces, where we can end up
here:

ld-linux-x86-64.so.2`___lldb_unnamed_symbol95$$ld-linux-x86-64.so.2:
0x77df04e0 <+0>:  48 83 ec 38
 subq   $0x38, %rsp
0x77df04e4 <+4>:  48 89 04 24
 movq   %rax, (%rsp)
0x77df04e8 <+8>:  48 89 4c 24 08
 movq   %rcx, 0x8(%rsp)
0x77df04ed <+13>: 48 89 54 24 10
 movq   %rdx, 0x10(%rsp)
0x77df04f2 <+18>: 48 89 74 24 18
 movq   %rsi, 0x18(%rsp)
0x77df04f7 <+23>: 48 89 7c 24 20
 movq   %rdi, 0x20(%rsp)
0x77df04fc <+28>: 4c 89 44 24 28
 movq   %r8, 0x28(%rsp)
0x77df0501 <+33>: 4c 89 4c 24 30
 movq   %r9, 0x30(%rsp)
0x77df0506 <+38>: 48 8b 74 24 40
 movq   0x40(%rsp), %rsi
0x77df050b <+43>: 48 8b 7c 24 38
 movq   0x38(%rsp), %rdi
0x77df0510 <+48>: e8 4b 8f ff ff
 callq  0x77de9460;
___lldb_unnamed_symbol54$$ld-linux-x86-64.so.2
0x77df0515 <+53>: 49 89 c3
 movq   %rax, %r11
0x77df0518 <+56>: 4c 8b 4c 24 30
 movq   0x30(%rsp), %r9
0x77df051d <+61>: 4c 8b 44 24 28
 movq   0x28(%rsp), %r8
0x77df0522 <+66>: 48 8b 7c 24 20
 movq   0x20(%rsp), %rdi
0x77df0527 <+71>: 48 8b 74 24 18
 movq   0x18(%rsp), %rsi
0x77df052c <+76>: 48 8b 54 24 10
 movq   0x10(%rsp), %rdx
0x77df0531 <+81>: 48 8b 4c 24 08
 movq   0x8(%rsp), %rcx
->  0x77df0536 <+86>: 48 8b 04 24
 movq   (%rsp), %rax
0x77df053a <+90>: 48 83 c4 48
 addq   $0x48, %rsp
0x77df053e <+94>: 41 ff e3
 jmpq   *%r11
0x77df0541 <+97>: 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
 nopw   %cs:(%rax,%rax)


image show-unwind --address 0x77df0536
UNWIND PLANS for
ld-linux-x86-64.so.2`___lldb_unnamed_symbol95$$ld-linux-x86-64.so.2
(start addr 0x77df04e0)

Asynchronous (not restricted to call-sites) UnwindPlan is 'assembly
insn profiling'
Synchronous (restricted to call-sites) UnwindPlan is 'eh_frame CFI'

Assembly language inspection UnwindPlan:
This UnwindPlan originally sourced from assembly insn profiling
This UnwindPlan is sourced from the compiler: no.
This UnwindPlan is valid at all instruction locations: yes.
Address range of this UnwindPlan: [ld-linux-x86-64.so.2..text +
88576-0x00015a70)
row[0]:0: CFA=rsp +8 => rsp=CFA+0 rip=[CFA-8]
row[1]:4: CFA=rsp+64 => rsp=CFA+0 rip=[CFA-8]
row[2]:   94: CFA=rsp -8 => rsp=CFA+0 rip=[CFA-8]

eh_frame UnwindPlan:
This UnwindPlan originally sourced from eh_frame CFI
This UnwindPlan is sourced from the compiler: yes.
This UnwindPlan is valid at all instruction locations: no.
Address range of this UnwindPlan: [ld-linux-x86-64.so.2..text +
88576-0x00015a61)
row[0]:0: CFA=rsp+24 => rip=[CFA-8]
row[1]:4: CFA=rsp+80 => rip=[CFA-8]
row[2]:   94: CFA=rsp +8 => rip=[CFA-8]



On Wed, Jun 1, 2016 at 11:38 PM, Jason Molenda  wrote:

> It gets so tricky!  It's hard for the unwinder to tell the difference
> between a real valid stack unwind and random data giving lots of "frames".
>
> It sounds like the problem that needs fixing is to figure out why the
> assembly unwind is wrong for frame 0.  What do you get for
>
> disass -a 
>
> image show-unwind -a 
>
> ?
>
>
> > On Jun 1, 2016, at 12:56 AM, Ravitheja Addepally <
> ravithejaw...@gmail.com> wrote:
> >
> > Ok , currently the problem that I am facing is that there are cases in
> which eh_frame should have been used for frame 0 but it isn't and the
> assembly unwind just gives wrong information which could only be detected
> if the debugger tried to extract more frames. Now the usage of
> AddOneMoreFrame in UnwindLLDB is to try to get more than one frames in the
> stack. I want to run both the unwinders and select the one that gives more
> number of frames.
> >
> > On Wed, Jun 1, 2016 at 12:27 AM, Jason Molenda 
> wrote:
> >
> > > On May 31, 2016, at 11:31 AM, jing...@apple.com wrote:
> > >
> > >
> > >> On May 31, 2016, at 12:52 AM, Ravitheja Addepally via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > >>
> > >> Hello,
> > >>  I posted this query a while ago, i still have no answers, I am
> currently working on Bug 27687 (PrintStackTraces), so the reason for the
> failure is the erroneous unwinding of the frames from the zeroth frame. The
> error is not detected in AddOneMoreFrame, since it only checks for 2 more
> frames, if it was checking more frames in AddOneMoreFrame, it would have
> detected the error. Now my questions are ->
> > >>
> > >> ->  is that is there any specific reason for only checking 2 frames
> instead of more ?
> > >
> > > The stepping machinery uses the unwinder on each stop to figure out
> whether it has stepped in or out, which is fairly performance sensitive, so
> we don't want AddOneMoreFrame to do more work than it has to.
> >
> >
> > Most common case for a bad unwind, where the unwinder is stuck in a
> loop, is a single stack frame repeating.  I've seen loops as much as six
> frames repeating (which are not actually a series of recursive calls) but
> it's les

[lldb-dev] Switching to git (Windows experience) (was re:[cfe-dev] GitHub anyone?)

[Aaron Ballman via lldb-dev]

On Wed, Jun 1, 2016 at 6:31 PM, Renato Golin  wrote:
> I think we should start two other threads: one about git tooling on Windows
> and one about infrastructure problems migrating to git.

Some developers on Windows prefer to use GUI tools like TortoiseSVN to
command line tools for version control. The last time I tried
TortoiseGit on Windows (which was over a year ago), it did not feel
ready for production use on a complex project to me (I had crashes on
simple operations, and it seems I was not alone in seeing flaky
behavior: https://gitlab.com/tortoisegit/tortoisegit/issues/1738 and
https://gitlab.com/tortoisegit/tortoisegit/issues/2494 as examples).

Are there suitable GUI tools for git on Windows for projects as
complex as LLVM? I believe MSVC has some integration, but I've not
used it before. Perhaps other tools exist that match the integration
and stability that TortoiseSVN has with Explorer?

I bring this up as a possible minor concern because asking people to
switch from one set of command line commands to another set of command
line commands is a different beast than asking people to switch from
Explorer-integrated menus and dialogs to the command line (that's a
drastically different workflow to achieve the same end result of
source code version control).

~Aaron
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] Switching to git (Windows experience) (was re: GitHub anyone?)

[Dennis Luehring via lldb-dev]

Am 02.06.2016 um 14:43 schrieb Aaron Ballman via cfe-dev:

On Wed, Jun 1, 2016 at 6:31 PM, Renato Golin  wrote:
> I think we should start two other threads: one about git tooling on Windows
> and one about infrastructure problems migrating to git.

Some developers on Windows prefer to use GUI tools like TortoiseSVN to
command line tools for version control. The last time I tried
TortoiseGit on Windows (which was over a year ago), it did not feel
ready for production use on a complex project to me (I had crashes on
simple operations, and it seems I was not alone in seeing flaky
behavior: https://gitlab.com/tortoisegit/tortoisegit/issues/1738 and
https://gitlab.com/tortoisegit/tortoisegit/issues/2494 as examples).

Are there suitable GUI tools for git on Windows for projects as
complex as LLVM? I believe MSVC has some integration, but I've not
used it before. Perhaps other tools exist that match the integration
and stability that TortoiseSVN has with Explorer?
im using a combination of TortoiseGit (which works very well), Git 
Extensions (https://gitextensions.github.io/)

and GitKraken (https://www.gitkraken.com/)
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Switching to git (Windows experience) (was re:[cfe-dev] GitHub anyone?)

[Renato Golin via lldb-dev]

On 2 June 2016 at 13:43, Aaron Ballman via lldb-dev
 wrote:
> Are there suitable GUI tools for git on Windows for projects as
> complex as LLVM? I believe MSVC has some integration, but I've not
> used it before. Perhaps other tools exist that match the integration
> and stability that TortoiseSVN has with Explorer?

Have you tried any of these?

https://git-scm.com/downloads/guis

I've tried git-cola and gitg on Linux, and neither I nor my son liked
it enough to move from command line to a GUI. But we're not GUI folks,
so it could be that. We also tried some Android clients, and they are
crude.

Though, that GitHub app looks really nice!

cheers,
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] GitHub anyone?

[Renato Golin via lldb-dev]

A little summary...

After a lot of discussion, I think we converged to a few issues that
we need to solved before we finally decide to move.

Firstly, the responses were overwhelmingly positive (I counted 20 of
the ~25 people strongly supporting and another 2~3 weakly supporting).
This is a good indication that the move could be very beneficial to
the community as a whole, including downstream infrastructure, not
just the reduction in upstream infrastructure admin costs.

But that doesn't mean we have cleared up all the issues...


The benefits I gathered from the thread:

 * Infrastructure admin (not just server costs) is too expensive.
We're not sysadmins and maintaining all the tools is a full time job.
Volunteering works for odd problems, not for production services.
Furthermore, most of the infrastructure we need is covered by
GitHub/Lab/BB for free, on a scale that we would not have, even with a
full time sysadmin. Gratis.

 * Having one official repository instead of two is beneficial to most
developers. A lot of people (most people replying on this thread), use
Git in addition to SVN. Git also seems to be used more on validation
infrastructure than SVN (no example was put forward on this thread, at
least), due to the simplicity of controlling the repository and the
tools available. Reports of how teams decided to script Git to have
linear behaviour instead of falling back to SVN are enlightening.

 * Git developer tooling is a growing trend, while SVN tooling is
dying. This is not just about GUIs, but repository management (GitHub,
GitLab, BitBucket, etc versus SourceForge), bisects, branches,
remotes, hooks, workdir, submodules and all the new development seem
to be done on Git nowadays, not SVN. Windows may be an odd one related
to GUIs, but Visual Studio has Git integration and I hear it's similar
to the other MSVC VCSs. GitHub's desktop interface seems pretty cool,
too.

 * Web repositories make it *a lot* easier to create add-hoc pull
requests by non-developers, which could boost the number of
contributions and future contributors, as well as external projects
using LLVM components.

 * GitHub's SVN RW interface has been reported to work well for
simpler projects, but we need a more thorough examination before
declare it good enough for our purposes.

 * All reports on the thread pointed that downstream infrastructure is
already using Git, so that's one less problem to worry about if we do
move.


The issues that were raised:

 * Co-dependent patches already break buildbots, but the sequential ID
helps us identify and ignore. They will continue to break, even if we
use git sub-modules, so that doesn't change much, but it will be
harder to spot the issue. Server side hooks may help, as well as
sub-modules.

 * Windows tooling may be an issue. There's a separate thread handling
that part, so I won't cover it here. But I have to say it wasn't by a
long shot a resonant problem. It may also have some problem with
symlinks and in-tree checkouts (when interacting with llvm-projects
and sub-modules).

 * Sub-modules may help with a lot of the current relationship we have
inside the SVN repo, but it also has some problems. Namely they:
   - require a modern version of git (1.7/1.9), but that's 2013 onward.
   - may need additional server side scripting, but we can keep that
in another repo to control it.
   - won't replace SVN's monotonic IDs, but do we *really* need them?
 Sub-modules have a bad fame, I gather, but people in the thread
reported success on using it to build validation and release
infrastructure as well as doing bisects, checking out code, etc. We
probably need some documentation on how to do these things, as well as
some scripts to help people work out the dependencies (or use them).

 * GitHub/Lab/BB are not perfect. They have some interface issues, but
nothing more serious than we already have on our current
infrastructure. We'll probably have to keep Bugzilla (as GitHub's own
is really poor), but we can replace all our repos (SVN, Git),
visualisation tools (ViewVC, Klaus) and Phabricator.

Of all those issues, Windows tooling is a minor problem that shouldn't
impact decision that much and sub-modules need a lot of ironing out to
be considered good enough. My *personal* take away is that sub-modules
(or an alternative server side solution) is the only strong technical
issue we need to solve before we decide.


  How does a move look like?

If we decide to move, the proposed schedule is something like this:

STEP #1 : Pre Move

0. Update docs to mention the move, so people are aware the it's going on.
1. Register an official GitHub project with the LLVM foundation.
2. Setup another (read-only) mirror of llvm.org/git at this GitHub project
3. Make sure we have a la llvm-project-submodules setup in the
official account. (Optional or necessary for the buildbots?)
4. Make sure bisecting with llvm-project-submodules is a good experience
5. Make sure no one has any blocker

STEP #2

Re: [lldb-dev] [cfe-dev] GitHub anyone?

[Anton Korobeynikov via lldb-dev]

Renato,

> Firstly, the responses were overwhelmingly positive (I counted 20 of
> the ~25 people strongly supporting and another 2~3 weakly supporting).
> This is a good indication that the move could be very beneficial to
> the community as a whole, including downstream infrastructure, not
> just the reduction in upstream infrastructure admin costs.
I'm not quite sure that this might be a good indication. It might be
possible that we're just seeing the tip of the iceberg. Maybe we
should have some sort of survey so we could collect more opinions?

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Tanya Lattner via lldb-dev]

I personally find this email thread very hard to follow and read (this isn’t 
anyones fault.. its just a lot of replies). I am sure others do as well. I 
think it would be good to have a form/survey of some sort that can get feedback 
from users such as: who they are, how they use LLVM/contributions/etc,  if they 
are pro-github move, how it impacts them, etc. People could then submit their 
feedback in an organized way and we could get a better idea of how the 
community feels on the topic. 

I am happy to try to set something like this up.

-Tanya

> On Jun 2, 2016, at 8:48 AM, Renato Golin via llvm-dev 
>  wrote:
> 
> A little summary...
> 
> After a lot of discussion, I think we converged to a few issues that
> we need to solved before we finally decide to move.
> 
> Firstly, the responses were overwhelmingly positive (I counted 20 of
> the ~25 people strongly supporting and another 2~3 weakly supporting).
> This is a good indication that the move could be very beneficial to
> the community as a whole, including downstream infrastructure, not
> just the reduction in upstream infrastructure admin costs.
> 
> But that doesn't mean we have cleared up all the issues...
> 
> 
>The benefits I gathered from the thread:
> 
> * Infrastructure admin (not just server costs) is too expensive.
> We're not sysadmins and maintaining all the tools is a full time job.
> Volunteering works for odd problems, not for production services.
> Furthermore, most of the infrastructure we need is covered by
> GitHub/Lab/BB for free, on a scale that we would not have, even with a
> full time sysadmin. Gratis.
> 
> * Having one official repository instead of two is beneficial to most
> developers. A lot of people (most people replying on this thread), use
> Git in addition to SVN. Git also seems to be used more on validation
> infrastructure than SVN (no example was put forward on this thread, at
> least), due to the simplicity of controlling the repository and the
> tools available. Reports of how teams decided to script Git to have
> linear behaviour instead of falling back to SVN are enlightening.
> 
> * Git developer tooling is a growing trend, while SVN tooling is
> dying. This is not just about GUIs, but repository management (GitHub,
> GitLab, BitBucket, etc versus SourceForge), bisects, branches,
> remotes, hooks, workdir, submodules and all the new development seem
> to be done on Git nowadays, not SVN. Windows may be an odd one related
> to GUIs, but Visual Studio has Git integration and I hear it's similar
> to the other MSVC VCSs. GitHub's desktop interface seems pretty cool,
> too.
> 
> * Web repositories make it *a lot* easier to create add-hoc pull
> requests by non-developers, which could boost the number of
> contributions and future contributors, as well as external projects
> using LLVM components.
> 
> * GitHub's SVN RW interface has been reported to work well for
> simpler projects, but we need a more thorough examination before
> declare it good enough for our purposes.
> 
> * All reports on the thread pointed that downstream infrastructure is
> already using Git, so that's one less problem to worry about if we do
> move.
> 
> 
>The issues that were raised:
> 
> * Co-dependent patches already break buildbots, but the sequential ID
> helps us identify and ignore. They will continue to break, even if we
> use git sub-modules, so that doesn't change much, but it will be
> harder to spot the issue. Server side hooks may help, as well as
> sub-modules.
> 
> * Windows tooling may be an issue. There's a separate thread handling
> that part, so I won't cover it here. But I have to say it wasn't by a
> long shot a resonant problem. It may also have some problem with
> symlinks and in-tree checkouts (when interacting with llvm-projects
> and sub-modules).
> 
> * Sub-modules may help with a lot of the current relationship we have
> inside the SVN repo, but it also has some problems. Namely they:
>   - require a modern version of git (1.7/1.9), but that's 2013 onward.
>   - may need additional server side scripting, but we can keep that
> in another repo to control it.
>   - won't replace SVN's monotonic IDs, but do we *really* need them?
> Sub-modules have a bad fame, I gather, but people in the thread
> reported success on using it to build validation and release
> infrastructure as well as doing bisects, checking out code, etc. We
> probably need some documentation on how to do these things, as well as
> some scripts to help people work out the dependencies (or use them).
> 
> * GitHub/Lab/BB are not perfect. They have some interface issues, but
> nothing more serious than we already have on our current
> infrastructure. We'll probably have to keep Bugzilla (as GitHub's own
> is really poor), but we can replace all our repos (SVN, Git),
> visualisation tools (ViewVC, Klaus) and Phabricator.
> 
> Of all those issues, Windows tooling is a minor problem that shouldn't
> impact decision that much and sub-modules n

Re: [lldb-dev] [cfe-dev] Switching to git (Windows experience) (was re: GitHub anyone?)

[Diana Picus via lldb-dev]

You could try Git GUI [1]. I don't know if it's any good, I've only
used Git BASH on Windows (never had any problems with it).

Diana

[1] https://git-for-windows.github.io/

On 2 June 2016 at 15:43, Aaron Ballman via cfe-dev
 wrote:
> On Wed, Jun 1, 2016 at 6:31 PM, Renato Golin  wrote:
>> I think we should start two other threads: one about git tooling on Windows
>> and one about infrastructure problems migrating to git.
>
> Some developers on Windows prefer to use GUI tools like TortoiseSVN to
> command line tools for version control. The last time I tried
> TortoiseGit on Windows (which was over a year ago), it did not feel
> ready for production use on a complex project to me (I had crashes on
> simple operations, and it seems I was not alone in seeing flaky
> behavior: https://gitlab.com/tortoisegit/tortoisegit/issues/1738 and
> https://gitlab.com/tortoisegit/tortoisegit/issues/2494 as examples).
>
> Are there suitable GUI tools for git on Windows for projects as
> complex as LLVM? I believe MSVC has some integration, but I've not
> used it before. Perhaps other tools exist that match the integration
> and stability that TortoiseSVN has with Explorer?
>
> I bring this up as a possible minor concern because asking people to
> switch from one set of command line commands to another set of command
> line commands is a different beast than asking people to switch from
> Explorer-integrated menus and dialogs to the command line (that's a
> drastically different workflow to achieve the same end result of
> source code version control).
>
> ~Aaron
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[Scott Warren via lldb-dev]

My two cents worth: our group tries very hard to avoid Git because we find it 
immature, hard to use, and unreliable. I know others feel differently but our 
vote is to stay with SVN. If distributed repositories are a priority we’d be 
much happier with Mercurial.

skw


> On Jun 2, 2016, at 11:21 AM, Tanya Lattner via cfe-dev 
>  wrote:
> 
> I personally find this email thread very hard to follow and read (this isn’t 
> anyones fault.. its just a lot of replies). I am sure others do as well. I 
> think it would be good to have a form/survey of some sort that can get 
> feedback from users such as: who they are, how they use 
> LLVM/contributions/etc,  if they are pro-github move, how it impacts them, 
> etc. People could then submit their feedback in an organized way and we could 
> get a better idea of how the community feels on the topic. 
> 
> I am happy to try to set something like this up.
> 
> -Tanya
> 
>> On Jun 2, 2016, at 8:48 AM, Renato Golin via llvm-dev 
>>  wrote:
>> 
>> A little summary...
>> 
>> After a lot of discussion, I think we converged to a few issues that
>> we need to solved before we finally decide to move.
>> 
>> Firstly, the responses were overwhelmingly positive (I counted 20 of
>> the ~25 people strongly supporting and another 2~3 weakly supporting).
>> This is a good indication that the move could be very beneficial to
>> the community as a whole, including downstream infrastructure, not
>> just the reduction in upstream infrastructure admin costs.
>> 
>> But that doesn't mean we have cleared up all the issues...
>> 
>> 
>>   The benefits I gathered from the thread:
>> 
>> * Infrastructure admin (not just server costs) is too expensive.
>> We're not sysadmins and maintaining all the tools is a full time job.
>> Volunteering works for odd problems, not for production services.
>> Furthermore, most of the infrastructure we need is covered by
>> GitHub/Lab/BB for free, on a scale that we would not have, even with a
>> full time sysadmin. Gratis.
>> 
>> * Having one official repository instead of two is beneficial to most
>> developers. A lot of people (most people replying on this thread), use
>> Git in addition to SVN. Git also seems to be used more on validation
>> infrastructure than SVN (no example was put forward on this thread, at
>> least), due to the simplicity of controlling the repository and the
>> tools available. Reports of how teams decided to script Git to have
>> linear behaviour instead of falling back to SVN are enlightening.
>> 
>> * Git developer tooling is a growing trend, while SVN tooling is
>> dying. This is not just about GUIs, but repository management (GitHub,
>> GitLab, BitBucket, etc versus SourceForge), bisects, branches,
>> remotes, hooks, workdir, submodules and all the new development seem
>> to be done on Git nowadays, not SVN. Windows may be an odd one related
>> to GUIs, but Visual Studio has Git integration and I hear it's similar
>> to the other MSVC VCSs. GitHub's desktop interface seems pretty cool,
>> too.
>> 
>> * Web repositories make it *a lot* easier to create add-hoc pull
>> requests by non-developers, which could boost the number of
>> contributions and future contributors, as well as external projects
>> using LLVM components.
>> 
>> * GitHub's SVN RW interface has been reported to work well for
>> simpler projects, but we need a more thorough examination before
>> declare it good enough for our purposes.
>> 
>> * All reports on the thread pointed that downstream infrastructure is
>> already using Git, so that's one less problem to worry about if we do
>> move.
>> 
>> 
>>   The issues that were raised:
>> 
>> * Co-dependent patches already break buildbots, but the sequential ID
>> helps us identify and ignore. They will continue to break, even if we
>> use git sub-modules, so that doesn't change much, but it will be
>> harder to spot the issue. Server side hooks may help, as well as
>> sub-modules.
>> 
>> * Windows tooling may be an issue. There's a separate thread handling
>> that part, so I won't cover it here. But I have to say it wasn't by a
>> long shot a resonant problem. It may also have some problem with
>> symlinks and in-tree checkouts (when interacting with llvm-projects
>> and sub-modules).
>> 
>> * Sub-modules may help with a lot of the current relationship we have
>> inside the SVN repo, but it also has some problems. Namely they:
>>  - require a modern version of git (1.7/1.9), but that's 2013 onward.
>>  - may need additional server side scripting, but we can keep that
>> in another repo to control it.
>>  - won't replace SVN's monotonic IDs, but do we *really* need them?
>> Sub-modules have a bad fame, I gather, but people in the thread
>> reported success on using it to build validation and release
>> infrastructure as well as doing bisects, checking out code, etc. We
>> probably need some documentation on how to do these things, as well as
>> some scripts to help people work out the dependencies (or use them).
>>

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Joerg Sonnenberger via lldb-dev]

On Thu, Jun 02, 2016 at 04:48:36PM +0100, Renato Golin via llvm-dev wrote:
>  * Git developer tooling is a growing trend, while SVN tooling is
> dying. This is not just about GUIs, but repository management (GitHub,
> GitLab, BitBucket, etc versus SourceForge), bisects, branches,
> remotes, hooks, workdir, submodules and all the new development seem
> to be done on Git nowadays, not SVN. Windows may be an odd one related
> to GUIs, but Visual Studio has Git integration and I hear it's similar
> to the other MSVC VCSs. GitHub's desktop interface seems pretty cool,
> too.

I find it somewhat dishonest that the alternatives are Subversion and
Git. I don't see any reason why Mercurial is excluded from the list.
Given the existing Python requirement for a lot of the LLVM tooling,
that part is a non-issue. It has much better Windows support.

>  * Web repositories make it *a lot* easier to create add-hoc pull
> requests by non-developers, which could boost the number of
> contributions and future contributors, as well as external projects
> using LLVM components.

I hear this assertion, but I don't buy it. As I said on IRC, if I follow
the typical iteration process for patches from first (or even second and
third) time contributors, few such patches are directly acceptable.
That leaves the GitHub interface as inferior alternative to Phabricator.
It seems energy would be better spend on improving the latter, e.g. by
allowing registered users to trigger an integration test etc.

>  * Co-dependent patches already break buildbots, but the sequential ID
> helps us identify and ignore. They will continue to break, even if we
> use git sub-modules, so that doesn't change much, but it will be
> harder to spot the issue. Server side hooks may help, as well as
> sub-modules.

They also make bisecting across repository boundaries much easier. I
haven't heard any evidence that submodules properly deal with this.
Given that one of the primary interaction with the VCS for me is
bisection, anything making it more fragile or more difficult to work is
a huge no.

Joerg
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[Chris Bieneman via lldb-dev]

My personal 2 cents is that I’d love to see us move to github and a git-native 
workflow. I’m already on a mostly git workflow and the only thing that tears me 
out of it is git-svn, which corrupts itself way too often.

As a late-comer on the thread I do have a few thoughts I want to share based on 
the discussion.

(1) We really don’t know how many users are using git vs svn. What if we 
encouraged users on git to setup a commit-msg hook that appended text to the 
end of their commit messages to identify the commits as being from git?

Something like this -> http://reviews.llvm.org/P4788

Then we could figure out easily a rough approximation of how many of our 
developers are on git vs svn. Having that information would make a lot of these 
discussions more clear, and it would give us some level of empirical data.

(2) I strongly think merging repositories is a bad idea. In particular we 
support building clang without having an LLVM checkout by building against an 
installed LLVM. Merging the repositories would break this, and that may be an 
important feature. Similarly compiler-rt is used with GCC, so we need to 
support it not being in the LLVM repo. All of this gets messy.

(3) Submodules can be messy. I’d prefer if we had a solution where they were 
optional or something like the github llvm-project-submodule setup where the 
submodules are all part of a separate repository. We could even make it so that 
repository is updated by a bot only after a successful compile. That would be 
kinda cool.

-Chris


> On Jun 2, 2016, at 9:28 AM, Scott Warren via cfe-dev  
> wrote:
> 
> My two cents worth: our group tries very hard to avoid Git because we find it 
> immature, hard to use, and unreliable. I know others feel differently but our 
> vote is to stay with SVN. If distributed repositories are a priority we’d be 
> much happier with Mercurial.
> 
> skw
> 
> 
>> On Jun 2, 2016, at 11:21 AM, Tanya Lattner via cfe-dev 
>> mailto:cfe-...@lists.llvm.org>> wrote:
>> 
>> I personally find this email thread very hard to follow and read (this isn’t 
>> anyones fault.. its just a lot of replies). I am sure others do as well. I 
>> think it would be good to have a form/survey of some sort that can get 
>> feedback from users such as: who they are, how they use 
>> LLVM/contributions/etc,  if they are pro-github move, how it impacts them, 
>> etc. People could then submit their feedback in an organized way and we 
>> could get a better idea of how the community feels on the topic. 
>> 
>> I am happy to try to set something like this up.
>> 
>> -Tanya
>> 
>>> On Jun 2, 2016, at 8:48 AM, Renato Golin via llvm-dev 
>>>  wrote:
>>> 
>>> A little summary...
>>> 
>>> After a lot of discussion, I think we converged to a few issues that
>>> we need to solved before we finally decide to move.
>>> 
>>> Firstly, the responses were overwhelmingly positive (I counted 20 of
>>> the ~25 people strongly supporting and another 2~3 weakly supporting).
>>> This is a good indication that the move could be very beneficial to
>>> the community as a whole, including downstream infrastructure, not
>>> just the reduction in upstream infrastructure admin costs.
>>> 
>>> But that doesn't mean we have cleared up all the issues...
>>> 
>>> 
>>>  The benefits I gathered from the thread:
>>> 
>>> * Infrastructure admin (not just server costs) is too expensive.
>>> We're not sysadmins and maintaining all the tools is a full time job.
>>> Volunteering works for odd problems, not for production services.
>>> Furthermore, most of the infrastructure we need is covered by
>>> GitHub/Lab/BB for free, on a scale that we would not have, even with a
>>> full time sysadmin. Gratis.
>>> 
>>> * Having one official repository instead of two is beneficial to most
>>> developers. A lot of people (most people replying on this thread), use
>>> Git in addition to SVN. Git also seems to be used more on validation
>>> infrastructure than SVN (no example was put forward on this thread, at
>>> least), due to the simplicity of controlling the repository and the
>>> tools available. Reports of how teams decided to script Git to have
>>> linear behaviour instead of falling back to SVN are enlightening.
>>> 
>>> * Git developer tooling is a growing trend, while SVN tooling is
>>> dying. This is not just about GUIs, but repository management (GitHub,
>>> GitLab, BitBucket, etc versus SourceForge), bisects, branches,
>>> remotes, hooks, workdir, submodules and all the new development seem
>>> to be done on Git nowadays, not SVN. Windows may be an odd one related
>>> to GUIs, but Visual Studio has Git integration and I hear it's similar
>>> to the other MSVC VCSs. GitHub's desktop interface seems pretty cool,
>>> too.
>>> 
>>> * Web repositories make it *a lot* easier to create add-hoc pull
>>> requests by non-developers, which could boost the number of
>>> contributions and future contributors, as well as external projects
>>> using LLVM components.
>>> 
>>> * GitHub's SVN

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[via lldb-dev]

Saleem Abdulrasool via llvm-dev  writes:

> As long as a mechanism for bisecting across the repositories is worked
> out, definitely a +1 from me.

I have some git-subtree changes in the works (and used in production
here) that allows this quite naturally.

Not that I'm necessarily recommending git-subtree over git-submodule but
it is another option to look at.

  -David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[via lldb-dev]

Mehdi Amini via llvm-dev  writes:

>> Personally, I’m hugely in favor of moving llvm’s source hosting to
>> github at some point, despite the fact that I continue to dislike
>> git as a tool and consider monotonicly increasing version numbers to
>> be hugely beneficial.
>
> Getting a monotonically increasing revision number seems doable in git
> with some server-side scripting using git notes or named tags (yet to
> be seen is how to achieve it *reliably* with github hosting).
> However the challenge is more about sharing this number across
> repositories (i.e. having clang and llvm in sync). I can imagine some
> tooling for that, but with a github hosting it may still be fragile.

What exactly is the concrete benefit of monotonically increasing
revision numbers?  It's completely foreign to git's architecture.

Putting this requirement on git is going to severely limit how the
history is allowed to look.  Maybe that's what people want, I don't
know.  We certainly haven't missed them since moving to git.

 -David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[via lldb-dev]

Tim Northover via cfe-dev  writes:

> On 31 May 2016 at 13:45, Mehdi Amini via lldb-dev
>  wrote:
>> Apparently I wasn't very clear: llvm and clang (and the others
>> projects) would be simple decoupled, individual git
>> repositories. You would be able to check them out however you want
>> and commit to them individually.
>> There would be an extra "integration repository" on top that would
>> only provide the service that tells "r12345 is llvm:36c941c
>> clang:eaf492b compiler-rt:6d77ea5". This repository should be
>> managed transparently by some server-side integration.
>
> This actually sounds like a really good idea even if a full move to
> git gets blocked for some reason. It seems like it could be a fairly
> common requirement: I don't suppose you know of an existing script
> that could do it? If not, I may take a stab.

How do you get monotonically increasing number with a history graph?
There are multiple ways to linearize the history.

You can simply disallow merges I guess but that seems not much better
than just sticking with SVN.  GitHub's pull request model kind of breaks
down if you can't do merges.

   -David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On Jun 2, 2016, at 11:01 AM, d...@cray.com wrote:
> 
> Mehdi Amini via llvm-dev  writes:
> 
>>> Personally, I’m hugely in favor of moving llvm’s source hosting to
>>> github at some point, despite the fact that I continue to dislike
>>> git as a tool and consider monotonicly increasing version numbers to
>>> be hugely beneficial.
>> 
>> Getting a monotonically increasing revision number seems doable in git
>> with some server-side scripting using git notes or named tags (yet to
>> be seen is how to achieve it *reliably* with github hosting).
>> However the challenge is more about sharing this number across
>> repositories (i.e. having clang and llvm in sync). I can imagine some
>> tooling for that, but with a github hosting it may still be fragile.
> 
> What exactly is the concrete benefit of monotonically increasing
> revision numbers?  It's completely foreign to git's architecture.

I'm notified that bug is fixed in r12345, my binary says "clang -v" is r23456, 
if I observe the bug I know there is a problem immediately.
Another use case is that it provides a cross-repository reference.

I'm sure that if you lookup the previous discussion about moving to git (two 
years ago, and four years ago I believe), the threads contain plenty of 
arguments from people attached to it.
I don't want to play the "devil's advocate" here since I'm not that bothered by 
loosing this.

> 
> Putting this requirement on git is going to severely limit how the
> history is allowed to look.  Maybe that's what people want, I don't
> know.  We certainly haven't missed them since moving to git.

I'm personally fine with arbitrary history in git, but some people (I suspect 
many here) are attached to the linear history. 
So my impression is that such a move has more chances of being accepted by the 
community if we keep the same workflow (linear history + monotonic revision 
numbers), at least at first.


-- 
Mehdi

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[via lldb-dev]

Richard Smith via llvm-dev  writes:

> How would you ensure that two dependent changes on different
> repositories get the same revision number?
>
> That is not the case today and isn't (in my opinion) a problem we need
> to solve with this migration. If there's a small (1-2 revision) window
> in which things are broken, that's annoying but not a showstopper and
> not a regression.

With git-subtree you could commit both changes atomically in the "host"
repository, then split out the histories to the individual components.

 -David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] win64 "patch"

[Greg Clayton via lldb-dev]

Looks good.

> On Jun 2, 2016, at 1:40 AM, Carlo Kok via lldb-dev  
> wrote:
> 
> Seems win64 almost works fine out of the box. 1 minor thing is needed:
> 
> 
> diff --git 
> a/source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp 
> b/source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp
> index 103cff4..4b37c3f 100644
> --- a/source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp
> +++ b/source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp
> @@ -136,6 +136,8 @@ RegisterInfo g_register_infos[] = {
>  nullptr},
> };
> 
> +static size_t k_num_register_infos = llvm::array_lengthof(g_register_infos);
> +
> // Array of lldb register numbers used to define the set of all General 
> Purpose Registers
> uint32_t g_gpr_reg_indices[] = {eRegisterIndexRax, eRegisterIndexRbx,  
> eRegisterIndexRcx, eRegisterIndexRdx,
> eRegisterIndexRdi, eRegisterIndexRsi,  
> eRegisterIndexR8,  eRegisterIndexR9,
> @@ -169,7 +171,9 @@ RegisterContextWindows_x64::GetRegisterCount()
> const RegisterInfo *
> RegisterContextWindows_x64::GetRegisterInfoAtIndex(size_t reg)
> {
> -return &g_register_infos[reg];
> +   if (reg < k_num_register_infos)
> +   return &g_register_infos[reg];
> +   return NULL;
> }
> 
> size_t
> 
> 
> The unwind logic asks for the "return address register" which doesn't exist; 
> returns -1 and goes out of the bounds for g_register_infos.
> 
> -- 
> Carlo Kok
> RemObjects Software
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] GitHub anyone?

[via lldb-dev]

Florent Castelli via cfe-dev  writes:

> For a linear history, you can have GitHub doing a rebase when merging
> the changes instead of a merge. I would recommend to do that to keep
> the history clean and have less "fixup" or "wip" commits in the
> history. 

Non-linear history doesn't casue "fixup" commits.  It's perfectly fine
to clean up local history via git-rebase before pushing and doing a
merge commit via pull request.

There's a tradeoff on rebase vs. merge.  A merge commit allows you to
easily revert an entire line of development with a single commit, for
example.

Good arguments can be made for both and I don't really have a preference
one way or the other but I think it's a needed conversation for the
community to have.  Workflows are important.

   -David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On Jun 2, 2016, at 11:03 AM, d...@cray.com wrote:
> 
> Tim Northover via cfe-dev  writes:
> 
>> On 31 May 2016 at 13:45, Mehdi Amini via lldb-dev
>>  wrote:
>>> Apparently I wasn't very clear: llvm and clang (and the others
>>> projects) would be simple decoupled, individual git
>>> repositories. You would be able to check them out however you want
>>> and commit to them individually.
>>> There would be an extra "integration repository" on top that would
>>> only provide the service that tells "r12345 is llvm:36c941c
>>> clang:eaf492b compiler-rt:6d77ea5". This repository should be
>>> managed transparently by some server-side integration.
>> 
>> This actually sounds like a really good idea even if a full move to
>> git gets blocked for some reason. It seems like it could be a fairly
>> common requirement: I don't suppose you know of an existing script
>> that could do it? If not, I may take a stab.
> 
> How do you get monotonically increasing number with a history graph?

I think what we're trying to get is a "pushed" revision number, i.e. tracking 
the state of the upstream repositories at a given time.


> There are multiple ways to linearize the history.
> 
> You can simply disallow merges I guess but that seems not much better
> than just sticking with SVN.  GitHub's pull request model kind of breaks
> down if you can't do merges.

Github has an automatic "squashed" mode for pull requests now, I haven't tested 
in practice but it may help.

-- 
Mehdi

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[via lldb-dev]

Anton Korobeynikov via llvm-dev  writes:

> I'm not sure we will benefit from having *all* the subprojects in the
> single repository. This might affect pull / clone time significantly.
> Think about having lld, lldb along with llvm + clang in the single
> main repo.

I have a personal setup just like this (via git-subtree) and updates are
not slow at all.  Even the initial clone is not bad.

  -David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On Jun 2, 2016, at 9:21 AM, Tanya Lattner via llvm-dev 
>  wrote:
> 
> I personally find this email thread very hard to follow and read (this isn’t 
> anyones fault.. its just a lot of replies). I am sure others do as well. I 
> think it would be good to have a form/survey of some sort that can get 
> feedback from users such as: who they are, how they use 
> LLVM/contributions/etc,  if they are pro-github move, how it impacts them, 
> etc. People could then submit their feedback in an organized way and we could 
> get a better idea of how the community feels on the topic. 
> 
> I am happy to try to set something like this up.

I don't think it is a good idea to set this up like that without having a well 
defined plan first.
My idea is rather that we should first try to see what is doable in term of 
server-side hook and integration so that the "poll" is not about naked "svn vs 
git", but about "svn vs 
git-with-this-server-side-setup-that-preserve-our-workflow".

-- 
Mehdi



> 
> -Tanya
> 
>> On Jun 2, 2016, at 8:48 AM, Renato Golin via llvm-dev 
>>  wrote:
>> 
>> A little summary...
>> 
>> After a lot of discussion, I think we converged to a few issues that
>> we need to solved before we finally decide to move.
>> 
>> Firstly, the responses were overwhelmingly positive (I counted 20 of
>> the ~25 people strongly supporting and another 2~3 weakly supporting).
>> This is a good indication that the move could be very beneficial to
>> the community as a whole, including downstream infrastructure, not
>> just the reduction in upstream infrastructure admin costs.
>> 
>> But that doesn't mean we have cleared up all the issues...
>> 
>> 
>>   The benefits I gathered from the thread:
>> 
>> * Infrastructure admin (not just server costs) is too expensive.
>> We're not sysadmins and maintaining all the tools is a full time job.
>> Volunteering works for odd problems, not for production services.
>> Furthermore, most of the infrastructure we need is covered by
>> GitHub/Lab/BB for free, on a scale that we would not have, even with a
>> full time sysadmin. Gratis.
>> 
>> * Having one official repository instead of two is beneficial to most
>> developers. A lot of people (most people replying on this thread), use
>> Git in addition to SVN. Git also seems to be used more on validation
>> infrastructure than SVN (no example was put forward on this thread, at
>> least), due to the simplicity of controlling the repository and the
>> tools available. Reports of how teams decided to script Git to have
>> linear behaviour instead of falling back to SVN are enlightening.
>> 
>> * Git developer tooling is a growing trend, while SVN tooling is
>> dying. This is not just about GUIs, but repository management (GitHub,
>> GitLab, BitBucket, etc versus SourceForge), bisects, branches,
>> remotes, hooks, workdir, submodules and all the new development seem
>> to be done on Git nowadays, not SVN. Windows may be an odd one related
>> to GUIs, but Visual Studio has Git integration and I hear it's similar
>> to the other MSVC VCSs. GitHub's desktop interface seems pretty cool,
>> too.
>> 
>> * Web repositories make it *a lot* easier to create add-hoc pull
>> requests by non-developers, which could boost the number of
>> contributions and future contributors, as well as external projects
>> using LLVM components.
>> 
>> * GitHub's SVN RW interface has been reported to work well for
>> simpler projects, but we need a more thorough examination before
>> declare it good enough for our purposes.
>> 
>> * All reports on the thread pointed that downstream infrastructure is
>> already using Git, so that's one less problem to worry about if we do
>> move.
>> 
>> 
>>   The issues that were raised:
>> 
>> * Co-dependent patches already break buildbots, but the sequential ID
>> helps us identify and ignore. They will continue to break, even if we
>> use git sub-modules, so that doesn't change much, but it will be
>> harder to spot the issue. Server side hooks may help, as well as
>> sub-modules.
>> 
>> * Windows tooling may be an issue. There's a separate thread handling
>> that part, so I won't cover it here. But I have to say it wasn't by a
>> long shot a resonant problem. It may also have some problem with
>> symlinks and in-tree checkouts (when interacting with llvm-projects
>> and sub-modules).
>> 
>> * Sub-modules may help with a lot of the current relationship we have
>> inside the SVN repo, but it also has some problems. Namely they:
>>  - require a modern version of git (1.7/1.9), but that's 2013 onward.
>>  - may need additional server side scripting, but we can keep that
>> in another repo to control it.
>>  - won't replace SVN's monotonic IDs, but do we *really* need them?
>> Sub-modules have a bad fame, I gather, but people in the thread
>> reported success on using it to build validation and release
>> infrastructure as well as doing bisects, checking out code, etc. We
>> probably need some documentation on how to do these things

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[via lldb-dev]

Piotr Padlewski via llvm-dev  writes:

> I also find it bad idea to have it all in one repo. Right now when I
> develope clang-tidy, I don't have to recompile clang often because
> most of the commits in clang-estra doesn't require new clang fetures. 
> This is pretty nice if work on 2 core machine.

But if you're not touching clang, then it won't get recompiled.
git-subtree gets you the benefits of a single repository while still
allowing individual updates of components.

Again, this is just something to look at.  I have some git-subtree
enhancements not yet sent to upstream that I think would be important
for LLVM if the community decides to seriously look at using
git-subtree.

   -David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On Jun 2, 2016, at 9:28 AM, Scott Warren via llvm-dev 
>  wrote:
> 
> My two cents worth: our group tries very hard to avoid Git because we find it 
> immature, hard to use, and unreliable.

I'm willing to take such claims into account, but they would have to come with 
a technical justification. Just claiming "it is unreliable" does not make it a 
reality.

-- 
Mehdi



> I know others feel differently but our vote is to stay with SVN. If 
> distributed repositories are a priority we’d be much happier with Mercurial.
> 
> skw
> 
> 
>> On Jun 2, 2016, at 11:21 AM, Tanya Lattner via cfe-dev 
>>  wrote:
>> 
>> I personally find this email thread very hard to follow and read (this isn’t 
>> anyones fault.. its just a lot of replies). I am sure others do as well. I 
>> think it would be good to have a form/survey of some sort that can get 
>> feedback from users such as: who they are, how they use 
>> LLVM/contributions/etc,  if they are pro-github move, how it impacts them, 
>> etc. People could then submit their feedback in an organized way and we 
>> could get a better idea of how the community feels on the topic. 
>> 
>> I am happy to try to set something like this up.
>> 
>> -Tanya
>> 
>>> On Jun 2, 2016, at 8:48 AM, Renato Golin via llvm-dev 
>>>  wrote:
>>> 
>>> A little summary...
>>> 
>>> After a lot of discussion, I think we converged to a few issues that
>>> we need to solved before we finally decide to move.
>>> 
>>> Firstly, the responses were overwhelmingly positive (I counted 20 of
>>> the ~25 people strongly supporting and another 2~3 weakly supporting).
>>> This is a good indication that the move could be very beneficial to
>>> the community as a whole, including downstream infrastructure, not
>>> just the reduction in upstream infrastructure admin costs.
>>> 
>>> But that doesn't mean we have cleared up all the issues...
>>> 
>>> 
>>>  The benefits I gathered from the thread:
>>> 
>>> * Infrastructure admin (not just server costs) is too expensive.
>>> We're not sysadmins and maintaining all the tools is a full time job.
>>> Volunteering works for odd problems, not for production services.
>>> Furthermore, most of the infrastructure we need is covered by
>>> GitHub/Lab/BB for free, on a scale that we would not have, even with a
>>> full time sysadmin. Gratis.
>>> 
>>> * Having one official repository instead of two is beneficial to most
>>> developers. A lot of people (most people replying on this thread), use
>>> Git in addition to SVN. Git also seems to be used more on validation
>>> infrastructure than SVN (no example was put forward on this thread, at
>>> least), due to the simplicity of controlling the repository and the
>>> tools available. Reports of how teams decided to script Git to have
>>> linear behaviour instead of falling back to SVN are enlightening.
>>> 
>>> * Git developer tooling is a growing trend, while SVN tooling is
>>> dying. This is not just about GUIs, but repository management (GitHub,
>>> GitLab, BitBucket, etc versus SourceForge), bisects, branches,
>>> remotes, hooks, workdir, submodules and all the new development seem
>>> to be done on Git nowadays, not SVN. Windows may be an odd one related
>>> to GUIs, but Visual Studio has Git integration and I hear it's similar
>>> to the other MSVC VCSs. GitHub's desktop interface seems pretty cool,
>>> too.
>>> 
>>> * Web repositories make it *a lot* easier to create add-hoc pull
>>> requests by non-developers, which could boost the number of
>>> contributions and future contributors, as well as external projects
>>> using LLVM components.
>>> 
>>> * GitHub's SVN RW interface has been reported to work well for
>>> simpler projects, but we need a more thorough examination before
>>> declare it good enough for our purposes.
>>> 
>>> * All reports on the thread pointed that downstream infrastructure is
>>> already using Git, so that's one less problem to worry about if we do
>>> move.
>>> 
>>> 
>>>  The issues that were raised:
>>> 
>>> * Co-dependent patches already break buildbots, but the sequential ID
>>> helps us identify and ignore. They will continue to break, even if we
>>> use git sub-modules, so that doesn't change much, but it will be
>>> harder to spot the issue. Server side hooks may help, as well as
>>> sub-modules.
>>> 
>>> * Windows tooling may be an issue. There's a separate thread handling
>>> that part, so I won't cover it here. But I have to say it wasn't by a
>>> long shot a resonant problem. It may also have some problem with
>>> symlinks and in-tree checkouts (when interacting with llvm-projects
>>> and sub-modules).
>>> 
>>> * Sub-modules may help with a lot of the current relationship we have
>>> inside the SVN repo, but it also has some problems. Namely they:
>>> - require a modern version of git (1.7/1.9), but that's 2013 onward.
>>> - may need additional server side scripting, but we can keep that
>>> in another repo to control it.
>>> - won't replace SVN's monotonic IDs, but do we *really* need

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On Jun 2, 2016, at 10:53 AM, Chris Bieneman via llvm-dev 
>  wrote:
> 
> My personal 2 cents is that I’d love to see us move to github and a 
> git-native workflow. I’m already on a mostly git workflow and the only thing 
> that tears me out of it is git-svn, which corrupts itself way too often.
> 
> As a late-comer on the thread I do have a few thoughts I want to share based 
> on the discussion.
> 
> (1) We really don’t know how many users are using git vs svn. What if we 
> encouraged users on git to setup a commit-msg hook that appended text to the 
> end of their commit messages to identify the commits as being from git?
> 
> Something like this -> http://reviews.llvm.org/P4788 
> 
> 
> Then we could figure out easily a rough approximation of how many of our 
> developers are on git vs svn. Having that information would make a lot of 
> these discussions more clear, and it would give us some level of empirical 
> data.
> 
> (2) I strongly think merging repositories is a bad idea. In particular we 
> support building clang without having an LLVM checkout by building against an 
> installed LLVM. Merging the repositories would break this, and that may be an 
> important feature. Similarly compiler-rt is used with GCC, so we need to 
> support it not being in the LLVM repo. All of this gets messy.
> 
> (3) Submodules can be messy. I’d prefer if we had a solution where they were 
> optional or something like the github llvm-project-submodule setup where the 
> submodules are all part of a separate repository. We could even make it so 
> that repository is updated by a bot only after a successful compile. That 
> would be kinda cool.

I agree with all that, and indeed you 3) is definitively what I proposed very 
early in the thread. I think we should first clearly define what we can/can't 
do on this aspect before deciding on an eventual move.

-- 
Mehdi



> 
> -Chris
> 
> 
>> On Jun 2, 2016, at 9:28 AM, Scott Warren via cfe-dev > > wrote:
>> 
>> My two cents worth: our group tries very hard to avoid Git because we find 
>> it immature, hard to use, and unreliable. I know others feel differently but 
>> our vote is to stay with SVN. If distributed repositories are a priority 
>> we’d be much happier with Mercurial.
>> 
>> skw
>> 
>> 
>>> On Jun 2, 2016, at 11:21 AM, Tanya Lattner via cfe-dev 
>>> mailto:cfe-...@lists.llvm.org>> wrote:
>>> 
>>> I personally find this email thread very hard to follow and read (this 
>>> isn’t anyones fault.. its just a lot of replies). I am sure others do as 
>>> well. I think it would be good to have a form/survey of some sort that can 
>>> get feedback from users such as: who they are, how they use 
>>> LLVM/contributions/etc,  if they are pro-github move, how it impacts them, 
>>> etc. People could then submit their feedback in an organized way and we 
>>> could get a better idea of how the community feels on the topic. 
>>> 
>>> I am happy to try to set something like this up.
>>> 
>>> -Tanya
>>> 
 On Jun 2, 2016, at 8:48 AM, Renato Golin via llvm-dev 
 mailto:llvm-...@lists.llvm.org>> wrote:
 
 A little summary...
 
 After a lot of discussion, I think we converged to a few issues that
 we need to solved before we finally decide to move.
 
 Firstly, the responses were overwhelmingly positive (I counted 20 of
 the ~25 people strongly supporting and another 2~3 weakly supporting).
 This is a good indication that the move could be very beneficial to
 the community as a whole, including downstream infrastructure, not
 just the reduction in upstream infrastructure admin costs.
 
 But that doesn't mean we have cleared up all the issues...
 
 
  The benefits I gathered from the thread:
 
 * Infrastructure admin (not just server costs) is too expensive.
 We're not sysadmins and maintaining all the tools is a full time job.
 Volunteering works for odd problems, not for production services.
 Furthermore, most of the infrastructure we need is covered by
 GitHub/Lab/BB for free, on a scale that we would not have, even with a
 full time sysadmin. Gratis.
 
 * Having one official repository instead of two is beneficial to most
 developers. A lot of people (most people replying on this thread), use
 Git in addition to SVN. Git also seems to be used more on validation
 infrastructure than SVN (no example was put forward on this thread, at
 least), due to the simplicity of controlling the repository and the
 tools available. Reports of how teams decided to script Git to have
 linear behaviour instead of falling back to SVN are enlightening.
 
 * Git developer tooling is a growing trend, while SVN tooling is
 dying. This is not just about GUIs, but repository management (GitHub,
 GitLab, BitBucket, etc versus SourceForge), bisects, branches,
 remotes, hooks, workdir, submodu

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[via lldb-dev]

Matthias Braun via cfe-dev  writes:

> 3. Make sure we have ala llvm-project-submodules setup in the official
> account. (Optional or necessary for the buildbots?)

> 7. Make sure bisecting with llvm-project-submodules is a good experience

I would like to have a fuller discussion about how to handle the
multiple repositories before going forward.  Submodules is not the only
solution available and we should take some time to evaluate what's out
there.  There are definite downsides to submodules (and all the various
solutions) and I personally need to better understand the tradeoffs.

   -David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[Robinson, Paul via lldb-dev]

> > How do you get monotonically increasing number with a history graph?
> 
> I think what we're trying to get is a "pushed" revision number, i.e.
> tracking the state of the upstream repositories at a given time.

I think I've mentioned this before but internally we are (mostly) using
"rev-list --count --first-parent branch-name" which gives us a 
monotonically increasing number per-branch.  The --first-parent means 
each merge counts as one, which is enough for build-number uniqueness.
Unique sequential build numbers meet our internal needs.  If this number
gets incorporated into the version numbering self-reported by Clang/LLVM,
then it's not hard to map back onto git commits.
--paulr

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[James Y Knight via lldb-dev]

We could also think about using gerrit in the future to manage code reviews
and commits into the repository. (perhaps via the gerrithub.io hosted
platform, which also has github integration, including the ability to deal
with pull requests).

Gerrit already has pretty good support for cross-repository changes (via
assigning a bunch of commits to the same "topic", so they can be reviewed
together).

It also already supports making the submodule commits for the
"llvm-project" superproject. And it is supposed to "soon" support doing an
atomic commit of a "topic" across multiple repositories, which could then
show up as a single change in the "llvm-project" superproject repository. I
don't believe it does that atomically right now, but that's in the plans.

I have found gerrit a really nice code review system in the past for other
projects, and I'm a little afraid that github's PR system will not be
featureful enough by itself. But, maybe it will.

On Thu, Jun 2, 2016 at 2:06 PM, via cfe-dev  wrote:

> Richard Smith via llvm-dev  writes:
>
> > How would you ensure that two dependent changes on different
> > repositories get the same revision number?
> >
> > That is not the case today and isn't (in my opinion) a problem we need
> > to solve with this migration. If there's a small (1-2 revision) window
> > in which things are broken, that's annoying but not a showstopper and
> > not a regression.
>
> With git-subtree you could commit both changes atomically in the "host"
> repository, then split out the histories to the individual components.
>
>  -David
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On Jun 2, 2016, at 11:22 AM, Robinson, Paul  wrote:
> 
>>> How do you get monotonically increasing number with a history graph?
>> 
>> I think what we're trying to get is a "pushed" revision number, i.e.
>> tracking the state of the upstream repositories at a given time.
> 
> I think I've mentioned this before but internally we are (mostly) using
> "rev-list --count --first-parent branch-name" which gives us a 
> monotonically increasing number per-branch.  The --first-parent means 
> each merge counts as one, which is enough for build-number uniqueness.
> Unique sequential build numbers meet our internal needs.  If this number
> gets incorporated into the version numbering self-reported by Clang/LLVM,
> then it's not hard to map back onto git commits.

I think I've answered to this before but it does not help to solve the 
cross-repository problem, we need a "meta integration repository".

-- 
Mehdi

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On Jun 2, 2016, at 11:22 AM, d...@cray.com wrote:
> 
> Matthias Braun via cfe-dev  writes:
> 
>> 3. Make sure we have ala llvm-project-submodules setup in the official
>> account. (Optional or necessary for the buildbots?)
> 
>> 7. Make sure bisecting with llvm-project-submodules is a good experience
> 
> I would like to have a fuller discussion about how to handle the
> multiple repositories before going forward.  Submodules is not the only
> solution available and we should take some time to evaluate what's out
> there.  There are definite downsides to submodules (and all the various
> solutions) and I personally need to better understand the tradeoffs.

My opinion is that submodules or not is an implementation details. For the sake 
of this high-level discussion we should be able to keep it as "submodules" 
meaning "some system to integrate and manage different repositories coherently".
We should evaluate subtree as well, as you mentioned, but also the tradeoff of 
other tools like repo (Android).

-- 
Mehdi


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] GitHub anyone?

[via lldb-dev]

Renato Golin via cfe-dev  writes:

>  * Sub-modules may help with a lot of the current relationship we have
> inside the SVN repo, but it also has some problems. Namely they:
>- require a modern version of git (1.7/1.9), but that's 2013 onward.
>- may need additional server side scripting, but we can keep that
> in another repo to control it.
>- won't replace SVN's monotonic IDs, but do we *really* need them?
>  Sub-modules have a bad fame, I gather, but people in the thread
> reported success on using it to build validation and release
> infrastructure as well as doing bisects, checking out code, etc. We
> probably need some documentation on how to do these things, as well as
> some scripts to help people work out the dependencies (or use them).

I'd like to generate and add to your notes a list of submodule
alternatives so we can explore options.  Here's a start.  Not all of
these are equally good IMHO.

- Creating one big repository
- Simply require multiple clones + tooling for bisect
- git-subtree (with to-be-contributed enhancements)
- Google repo

-David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[via lldb-dev]

Mehdi Amini via llvm-dev  writes:

>> What exactly is the concrete benefit of monotonically increasing
>> revision numbers?  It's completely foreign to git's architecture.
>
> I'm notified that bug is fixed in r12345, my binary says "clang -v" is
> r23456, if I observe the bug I know there is a problem immediately.
> Another use case is that it provides a cross-repository reference.

I know this is just one example, but the clang version number can be set
to whatever we want to set it to.  It can include the most recent commit
date, for example.

My larger point is that in git, there is no time-based relationship
among commits if there are branches and merges, so a
monotonically-increasing number is misleading.

> I'm sure that if you lookup the previous discussion about moving to
> git (two years ago, and four years ago I believe), the threads contain
> plenty of arguments from people attached to it.
> I don't want to play the "devil's advocate" here since I'm not that bothered 
> by loosing this.

Sure.  And I'm sure there are use-cases I'm not familiar with.  I'm
simply asking the question because in my experience managing a gigantic
migration of our codebase, a move to git usually raises a bunch of
assumptions by people that may or may not actually be accurate.

A move to git (or any other revision system, really) is an opportunity
to re-examine workflows and assumptions.

>> Putting this requirement on git is going to severely limit how the
>> history is allowed to look.  Maybe that's what people want, I don't
>> know.  We certainly haven't missed them since moving to git.
>
> I'm personally fine with arbitrary history in git, but some people (I
> suspect many here) are attached to the linear history.
> So my impression is that such a move has more chances of being
> accepted by the community if we keep the same workflow (linear history
> + monotonic revision numbers), at least at first.

Yeah, I get that and I actually don't mind keeping a linear history.
But we definitely should branch for release.  Given release branches,
there are a number of questions and tradeoffs about how to backport
changes from master/latest development to a release.  Some of those
options break linear history.  This is the kind of workflow stuff we
should clarify if possible.

 -David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[Scott Warren via lldb-dev]

> they would have to come with a technical justification. Just claiming "it is 
> unreliable" does not make it a reality.

Of course I don't expect anyone to accept a claim because I say so. The 
relative merits of Git and SVN have been widely discussed for years and most 
interested parties have already formed an opinion. I am merely casting a vote 
based on mine.

skw

Sent from my iPhone

> On Jun 2, 2016, at 1:20 PM, Mehdi Amini  wrote:
> 
> 
>> On Jun 2, 2016, at 9:28 AM, Scott Warren via llvm-dev 
>>  wrote:
>> 
>> My two cents worth: our group tries very hard to avoid Git because we find 
>> it immature, hard to use, and unreliable.
> 
> I'm willing to take such claims into account, but they would have to come 
> with a technical justification. Just claiming "it is unreliable" does not 
> make it a reality.
> 
> -- 
> Mehdi
> 
> 
> 
>> I know others feel differently but our vote is to stay with SVN. If 
>> distributed repositories are a priority we’d be much happier with Mercurial.
>> 
>> skw
>> 
>> 
>>> On Jun 2, 2016, at 11:21 AM, Tanya Lattner via cfe-dev 
>>>  wrote:
>>> 
>>> I personally find this email thread very hard to follow and read (this 
>>> isn’t anyones fault.. its just a lot of replies). I am sure others do as 
>>> well. I think it would be good to have a form/survey of some sort that can 
>>> get feedback from users such as: who they are, how they use 
>>> LLVM/contributions/etc,  if they are pro-github move, how it impacts them, 
>>> etc. People could then submit their feedback in an organized way and we 
>>> could get a better idea of how the community feels on the topic. 
>>> 
>>> I am happy to try to set something like this up.
>>> 
>>> -Tanya
>>> 
 On Jun 2, 2016, at 8:48 AM, Renato Golin via llvm-dev 
  wrote:
 
 A little summary...
 
 After a lot of discussion, I think we converged to a few issues that
 we need to solved before we finally decide to move.
 
 Firstly, the responses were overwhelmingly positive (I counted 20 of
 the ~25 people strongly supporting and another 2~3 weakly supporting).
 This is a good indication that the move could be very beneficial to
 the community as a whole, including downstream infrastructure, not
 just the reduction in upstream infrastructure admin costs.
 
 But that doesn't mean we have cleared up all the issues...
 
 
 The benefits I gathered from the thread:
 
 * Infrastructure admin (not just server costs) is too expensive.
 We're not sysadmins and maintaining all the tools is a full time job.
 Volunteering works for odd problems, not for production services.
 Furthermore, most of the infrastructure we need is covered by
 GitHub/Lab/BB for free, on a scale that we would not have, even with a
 full time sysadmin. Gratis.
 
 * Having one official repository instead of two is beneficial to most
 developers. A lot of people (most people replying on this thread), use
 Git in addition to SVN. Git also seems to be used more on validation
 infrastructure than SVN (no example was put forward on this thread, at
 least), due to the simplicity of controlling the repository and the
 tools available. Reports of how teams decided to script Git to have
 linear behaviour instead of falling back to SVN are enlightening.
 
 * Git developer tooling is a growing trend, while SVN tooling is
 dying. This is not just about GUIs, but repository management (GitHub,
 GitLab, BitBucket, etc versus SourceForge), bisects, branches,
 remotes, hooks, workdir, submodules and all the new development seem
 to be done on Git nowadays, not SVN. Windows may be an odd one related
 to GUIs, but Visual Studio has Git integration and I hear it's similar
 to the other MSVC VCSs. GitHub's desktop interface seems pretty cool,
 too.
 
 * Web repositories make it *a lot* easier to create add-hoc pull
 requests by non-developers, which could boost the number of
 contributions and future contributors, as well as external projects
 using LLVM components.
 
 * GitHub's SVN RW interface has been reported to work well for
 simpler projects, but we need a more thorough examination before
 declare it good enough for our purposes.
 
 * All reports on the thread pointed that downstream infrastructure is
 already using Git, so that's one less problem to worry about if we do
 move.
 
 
 The issues that were raised:
 
 * Co-dependent patches already break buildbots, but the sequential ID
 helps us identify and ignore. They will continue to break, even if we
 use git sub-modules, so that doesn't change much, but it will be
 harder to spot the issue. Server side hooks may help, as well as
 sub-modules.
 
 * Windows tooling may be an issue. There's a separate thread handling
 that part, so I won't cover it here. But I have to say it wasn

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[via lldb-dev]

Mehdi Amini via llvm-dev  writes:

>> How do you get monotonically increasing number with a history graph?
>
> I think what we're trying to get is a "pushed" revision number,
> i.e. tracking the state of the upstream repositories at a given time.

Ah, that is something else entirely.  We use Stash/BitBucket here and it
numbers pull requests monotonically.  That numbering reflects when the
PR is created, NOT when it is merged, though.

>> You can simply disallow merges I guess but that seems not much better
>> than just sticking with SVN.  GitHub's pull request model kind of breaks
>> down if you can't do merges.
>
> Github has an automatic "squashed" mode for pull requests now, I
> haven't tested in practice but it may help.

IMHO squashed commits are a bad idea from a bisect perspective.  One of
the great benefits of git is the easy of creating small,
logically-independent commits that can be bisected.  Squashing
eliminates that advantage.

An automatic rebase of the branch and fast-forward merge would be a fine
way to maintain linear history.  I have no idea how/if GitHub supports
that though.

   -David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[via lldb-dev]

via llvm-dev  writes:

> Anton Korobeynikov via llvm-dev  writes:
>
>> I'm not sure we will benefit from having *all* the subprojects in the
>> single repository. This might affect pull / clone time significantly.
>> Think about having lld, lldb along with llvm + clang in the single
>> main repo.
>
> I have a personal setup just like this (via git-subtree) and updates are
> not slow at all.  Even the initial clone is not bad.

If it's not already, I'm happy to make this repository public so people
can play with it.  I will need to document how I use it, though.

  -David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[via lldb-dev]

Mehdi Amini via cfe-dev  writes:

> My opinion is that submodules or not is an implementation details. For
> the sake of this high-level discussion we should be able to keep it as
> "submodules" meaning "some system to integrate and manage different
> repositories coherently".
> We should evaluate subtree as well, as you mentioned, but also the
> tradeoff of other tools like repo (Android).

Fair enough.  It might be less confusing to use a term other that
"submodule" though.  I've used "superproject/subproject" in the past,
for example, and also "host repository" and "project repository."

  -David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On Jun 2, 2016, at 11:51 AM, d...@cray.com wrote:
> 
> Mehdi Amini via cfe-dev  writes:
> 
>> My opinion is that submodules or not is an implementation details. For
>> the sake of this high-level discussion we should be able to keep it as
>> "submodules" meaning "some system to integrate and manage different
>> repositories coherently".
>> We should evaluate subtree as well, as you mentioned, but also the
>> tradeoff of other tools like repo (Android).
> 
> Fair enough.  It might be less confusing to use a term other that
> "submodule" though.  I've used "superproject/subproject" in the past,
> for example, and also "host repository" and "project repository."

It does not even represent the full set of possibility: having a *separate* 
"integration repository" is what *I* think would be better. Some people 
proposed submodules in the llvm repo to track the subprojects, with a possible 
auto-update on push to the other repos. In this case there is no "super 
project" or separate repo.
I'm not trying to force a design on anyone here.

-- 
Mehdi
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Suspicious flag clash in SymbolContextItem enumeration

[Martin Filteau via lldb-dev]

Hi all,

I was investigating a bug when I saw something suspicious in: 

StackFrame.cpp:38

// The first bits in the flags are reserved for the SymbolContext::Scope bits
// so we know if we have tried to look up information in our internal symbol
// context (m_sc) already.
#define RESOLVED_FRAME_CODE_ADDR(uint32_t(eSymbolContextEverything + 1))
#define RESOLVED_FRAME_ID_SYMBOL_SCOPE  (RESOLVED_FRAME_CODE_ADDR << 1)
#define GOT_FRAME_BASE  (RESOLVED_FRAME_ID_SYMBOL_SCOPE << 1)
#define RESOLVED_VARIABLES  (GOT_FRAME_BASE << 1)
#define RESOLVED_GLOBAL_VARIABLES   (RESOLVED_VARIABLES << 1)

lldb-enumerations.h:310
FLAGS_ENUM(SymbolContextItem)
{
eSymbolContextTarget = (1u << 0), ///< Set when \a target is 
requested from a query, or was located in query results
eSymbolContextModule = (1u << 1), ///< Set when \a module is 
requested from a query, or was located in query results
eSymbolContextCompUnit   = (1u << 2), ///< Set when \a comp_unit is 
requested from a query, or was located in query results
eSymbolContextFunction   = (1u << 3), ///< Set when \a function is 
requested from a query, or was located in query results
eSymbolContextBlock  = (1u << 4), ///< Set when the deepest \a 
block is requested from a query, or was located in query results
eSymbolContextLineEntry  = (1u << 5), ///< Set when \a line_entry is 
requested from a query, or was located in query results
eSymbolContextSymbol = (1u << 6), ///< Set when \a symbol is 
requested from a query, or was located in query results
eSymbolContextEverything = ((eSymbolContextSymbol << 1) - 1u),  ///< 
Indicates to try and lookup everything up during a routine symbol context query.
eSymbolContextVariable   = (1u << 7)  ///< Set when \a global or static 
variable is requested from a query, or was located in query results.
  ///< eSymbolContextVariable is 
potentially expensive to lookup so it isn't included in
  ///< eSymbolContextEverything 
which stops it from being used during frame PC lookups and
  ///< many other potential address 
to symbol context lookups.
};

So, both RESOLVED_FRAME_CODE_ADDR and eSymbolContextVariable have the same 
value (0x80).

-Martin
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[via lldb-dev]

Mehdi Amini via cfe-dev  writes:

>> Fair enough.  It might be less confusing to use a term other that
>> "submodule" though.  I've used "superproject/subproject" in the past,
>> for example, and also "host repository" and "project repository."
>
> It does not even represent the full set of possibility: having a
> *separate* "integration repository" is what *I* think would be
> better. Some people proposed submodules in the llvm repo to track the
> subprojects, with a possible auto-update on push to the other
> repos. In this case there is no "super project" or separate repo.
> I'm not trying to force a design on anyone here.

In this case I would call the integration repository the superproject
and the submodules within it the subprojects.

I'm not proposing any particular terminology, just noting that
"submodule" is potentially confusing when we're talking about abstract
concepts.

BTW, I do highly prefer we keep the separate repositories we have and
integrate them in some way for build/bisect/release.  We currently only
use the LLVM portion of the ecosystem and having its repository separate
from clang/etc. eases our integration of the code into our products.  If
the community decided to go with one giant repository we could use
git-subtree to split out the LLVM history but it would be an extra step
for us.

-David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Inquiry regarding AddOneMoreFrame function in UnWindLLDB

[Jason Molenda via lldb-dev]

This has no eh_frame unwind instructions.  Even if we were using eh_frame at 
frame 0, you'd be out of luck.

I forget the exact order of fallbacks.  I think for frame 0 we try to use the 
assembly profile unwind ("async unwind plan") and if we can't do that we fall 
back to the eh_frame unwind ("sync unwind plan") and as a last resort we'll use 
the architecture default unwind plan.  Which, for a stack frame like this that 
doesn't do the usual push rbp; mov rsp, rbp sequence, means we'll skip at least 
one stack frame.

The assembly inspection unwind plan from AssemblyParse_x86 looks correct to me. 
This function saves some register on the stack (all of them argument or 
volatile registers, so that's weird & the assembly profiler probably won't 
record them; whatever), calls a function, restores the reg values and then 
jumps to the returned function pointer from that first func call.  Maybe this 
is some dynamic loader fixup routine for the first time an external function is 
called and the solib needs to be paged in.

You're stopped in the body of the function (offset 86) where the stack pointer 
is still as expected.  I'd have to think about that unwind entry for offset +94 
(if you were stopped on the jmp instruction) a bit more - that's a bit unusual. 
 But unless you're on the jmp, I can't see this unwind going wrong.


J

> On Jun 2, 2016, at 1:48 AM, Ravitheja Addepally  
> wrote:
> 
> Hello,
>  This is happening in TestPrintStackTraces, where we can end up here:
> ld-linux-x86-64.so.2`___lldb_unnamed_symbol95$$ld-linux-x86-64.so.2:
> 0x77df04e0 <+0>:  48 83 ec 38   subq  
>  $0x38, %rsp
> 0x77df04e4 <+4>:  48 89 04 24   movq  
>  %rax, (%rsp)
> 0x77df04e8 <+8>:  48 89 4c 24 08movq  
>  %rcx, 0x8(%rsp)
> 0x77df04ed <+13>: 48 89 54 24 10movq  
>  %rdx, 0x10(%rsp)
> 0x77df04f2 <+18>: 48 89 74 24 18movq  
>  %rsi, 0x18(%rsp)
> 0x77df04f7 <+23>: 48 89 7c 24 20movq  
>  %rdi, 0x20(%rsp)
> 0x77df04fc <+28>: 4c 89 44 24 28movq  
>  %r8, 0x28(%rsp)
> 0x77df0501 <+33>: 4c 89 4c 24 30movq  
>  %r9, 0x30(%rsp)
> 0x77df0506 <+38>: 48 8b 74 24 40movq  
>  0x40(%rsp), %rsi
> 0x77df050b <+43>: 48 8b 7c 24 38movq  
>  0x38(%rsp), %rdi
> 0x77df0510 <+48>: e8 4b 8f ff ffcallq 
>  0x77de9460; ___lldb_unnamed_symbol54$$ld-linux-x86-64.so.2
> 0x77df0515 <+53>: 49 89 c3  movq  
>  %rax, %r11
> 0x77df0518 <+56>: 4c 8b 4c 24 30movq  
>  0x30(%rsp), %r9
> 0x77df051d <+61>: 4c 8b 44 24 28movq  
>  0x28(%rsp), %r8
> 0x77df0522 <+66>: 48 8b 7c 24 20movq  
>  0x20(%rsp), %rdi
> 0x77df0527 <+71>: 48 8b 74 24 18movq  
>  0x18(%rsp), %rsi
> 0x77df052c <+76>: 48 8b 54 24 10movq  
>  0x10(%rsp), %rdx
> 0x77df0531 <+81>: 48 8b 4c 24 08movq  
>  0x8(%rsp), %rcx
> ->  0x77df0536 <+86>: 48 8b 04 24   movq  
>  (%rsp), %rax
> 0x77df053a <+90>: 48 83 c4 48   addq  
>  $0x48, %rsp
> 0x77df053e <+94>: 41 ff e3  jmpq  
>  *%r11
> 0x77df0541 <+97>: 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00  nopw  
>  %cs:(%rax,%rax)
> 
> 
> image show-unwind --address 0x77df0536
> UNWIND PLANS for 
> ld-linux-x86-64.so.2`___lldb_unnamed_symbol95$$ld-linux-x86-64.so.2 (start 
> addr 0x77df04e0)
> 
> Asynchronous (not restricted to call-sites) UnwindPlan is 'assembly insn 
> profiling'
> Synchronous (restricted to call-sites) UnwindPlan is 'eh_frame CFI'
> 
> Assembly language inspection UnwindPlan:
> This UnwindPlan originally sourced from assembly insn profiling
> This UnwindPlan is sourced from the compiler: no.
> This UnwindPlan is valid at all instruction locations: yes.
> Address range of this UnwindPlan: [ld-linux-x86-64.so.2..text + 
> 88576-0x00015a70)
> row[0]:0: CFA=rsp +8 => rsp=CFA+0 rip=[CFA-8] 
> row[1]:4: CFA=rsp+64 => rsp=CFA+0 rip=[CFA-8] 
> row[2]:   94: CFA=rsp -8 => rsp=CFA+0 rip=[CFA-8] 
> 
> eh_frame UnwindPlan:
> This UnwindPlan originally sourced from eh_frame CFI
> This UnwindPlan is sourced from the compiler: yes.
> This UnwindPlan is valid at all instruction locations: no.
> Address range of this UnwindPlan: [ld-linux-x86-64.so.2..text + 
> 88576-0x00015a61)
> row[0]:0: CFA=rsp+24 => rip=[CFA-8] 
> row[1]:4: CFA=rsp+80 => rip=[CF

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[Brian Cain via lldb-dev]

On Thu, Jun 2, 2016 at 11:21 AM, Tanya Lattner via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> I personally find this email thread very hard to follow and read (this
> isn’t anyones fault.. its just a lot of replies). I am sure others do as
> well. I think it would be good to have a form/survey of some sort that can
> get feedback from users such as: who they are, how they use
> LLVM/contributions/etc,  if they are pro-github move, how it impacts them,
> etc. People could then submit their feedback in an organized way and we
> could get a better idea of how the community feels on the topic.
>

While I sympathize, I wonder if a survey is appropriate.  It gives equal
weight to all voices but not all voices are equally impacted by the
pros/cons.  I am in favor of a github/lab/etc transition but I've only
lurked on the list and built/tested a couple of releases for older
platforms.  I would think opinions of those who have lots of work with
commits/reviews/content should probably be weighed heavier than mine.
Perhaps the survey could ask for a voluntary high/medium/low activity level
for normalizing the votes?

-- 
-Brian
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Switching to git (Windows experience) (was re:[cfe-dev] GitHub anyone?)

[Michael Spencer via lldb-dev]

On Thu, Jun 2, 2016 at 5:43 AM, Aaron Ballman via lldb-dev
 wrote:
> Some developers on Windows prefer to use GUI tools like TortoiseSVN to
> command line tools for version control. The last time I tried
> TortoiseGit on Windows (which was over a year ago), it did not feel
> ready for production use on a complex project to me (I had crashes on
> simple operations, and it seems I was not alone in seeing flaky
> behavior: https://gitlab.com/tortoisegit/tortoisegit/issues/1738 and
> https://gitlab.com/tortoisegit/tortoisegit/issues/2494 as examples).
>
> Are there suitable GUI tools for git on Windows for projects as
> complex as LLVM? I believe MSVC has some integration, but I've not
> used it before. Perhaps other tools exist that match the integration
> and stability that TortoiseSVN has with Explorer?
>
> I bring this up as a possible minor concern because asking people to
> switch from one set of command line commands to another set of command
> line commands is a different beast than asking people to switch from
> Explorer-integrated menus and dialogs to the command line (that's a
> drastically different workflow to achieve the same end result of
> source code version control).
>
> ~Aaron

I'm primarily a Windows user and have been using git for llvm for a
long time now. I use a combination of:

* SourceTree: log viewing and committing
* kdiff3: merging conflicts
* gitk: amending (SourceTree cannot yet handle unstaging chunks).
* command line: branching, svn dcommit, rebase, pull, merging,
applying patches, etc...

The only thing I actually have to use the command line for is rebase
-i, however I find the command line interface much better for the
things I use it for. It's also much faster for commits that aren't in
the past few days.

MSVS git integration is terrible and not worth touching at the moment.

- Michael Spencer
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[Tanya Lattner via lldb-dev]

> On Jun 2, 2016, at 3:59 PM, Brian Cain  wrote:
> 
>> On Thu, Jun 2, 2016 at 11:21 AM, Tanya Lattner via cfe-dev 
>>  wrote:
>> I personally find this email thread very hard to follow and read (this isn’t 
>> anyones fault.. its just a lot of replies). I am sure others do as well. I 
>> think it would be good to have a form/survey of some sort that can get 
>> feedback from users such as: who they are, how they use 
>> LLVM/contributions/etc,  if they are pro-github move, how it impacts them, 
>> etc. People could then submit their feedback in an organized way and we 
>> could get a better idea of how the community feels on the topic.
> 
> 
> While I sympathize, I wonder if a survey is appropriate.  It gives equal 
> weight to all voices but not all voices are equally impacted by the 
> pros/cons.  I am in favor of a github/lab/etc transition but I've only lurked 
> on the list and built/tested a couple of releases for older platforms.  I 
> would think opinions of those who have lots of work with 
> commits/reviews/content should probably be weighed heavier than mine.  
> Perhaps the survey could ask for a voluntary high/medium/low activity level 
> for normalizing the votes?
> 

Yes that's what I meant about asking for information about how they use LLVM 
and contributions. It would not be an anonymous survey. I just was thinking it 
would be better to have an organized way of getting votes/opinions without all 
the emails and discussion. I think discussion is important of course but it can 
be hard to follow everything and for some to chime in.

Anyways, just an idea.

-Tanya 

> -- 
> -Brian
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Tanya Lattner via lldb-dev]

> On Jun 2, 2016, at 12:18 PM, Mehdi Amini  wrote:
> 
> 
>> On Jun 2, 2016, at 9:21 AM, Tanya Lattner via llvm-dev 
>>  wrote:
>> 
>> I personally find this email thread very hard to follow and read (this isn’t 
>> anyones fault.. its just a lot of replies). I am sure others do as well. I 
>> think it would be good to have a form/survey of some sort that can get 
>> feedback from users such as: who they are, how they use 
>> LLVM/contributions/etc,  if they are pro-github move, how it impacts them, 
>> etc. People could then submit their feedback in an organized way and we 
>> could get a better idea of how the community feels on the topic. 
>> 
>> I am happy to try to set something like this up.
> 
> I don't think it is a good idea to set this up like that without having a 
> well defined plan first.
> My idea is rather that we should first try to see what is doable in term of 
> server-side hook and integration so that the "poll" is not about naked "svn 
> vs git", but about "svn vs 
> git-with-this-server-side-setup-that-preserve-our-workflow".
> 

Sure, I am fine with flushing out those details out. Just an idea to get a 
better idea of the consensus when the time comes.

-Tanya 


> -- 
> Mehdi
> 
> 
> 
>> 
>> -Tanya
>> 
>>> On Jun 2, 2016, at 8:48 AM, Renato Golin via llvm-dev 
>>>  wrote:
>>> 
>>> A little summary...
>>> 
>>> After a lot of discussion, I think we converged to a few issues that
>>> we need to solved before we finally decide to move.
>>> 
>>> Firstly, the responses were overwhelmingly positive (I counted 20 of
>>> the ~25 people strongly supporting and another 2~3 weakly supporting).
>>> This is a good indication that the move could be very beneficial to
>>> the community as a whole, including downstream infrastructure, not
>>> just the reduction in upstream infrastructure admin costs.
>>> 
>>> But that doesn't mean we have cleared up all the issues...
>>> 
>>> 
>>>  The benefits I gathered from the thread:
>>> 
>>> * Infrastructure admin (not just server costs) is too expensive.
>>> We're not sysadmins and maintaining all the tools is a full time job.
>>> Volunteering works for odd problems, not for production services.
>>> Furthermore, most of the infrastructure we need is covered by
>>> GitHub/Lab/BB for free, on a scale that we would not have, even with a
>>> full time sysadmin. Gratis.
>>> 
>>> * Having one official repository instead of two is beneficial to most
>>> developers. A lot of people (most people replying on this thread), use
>>> Git in addition to SVN. Git also seems to be used more on validation
>>> infrastructure than SVN (no example was put forward on this thread, at
>>> least), due to the simplicity of controlling the repository and the
>>> tools available. Reports of how teams decided to script Git to have
>>> linear behaviour instead of falling back to SVN are enlightening.
>>> 
>>> * Git developer tooling is a growing trend, while SVN tooling is
>>> dying. This is not just about GUIs, but repository management (GitHub,
>>> GitLab, BitBucket, etc versus SourceForge), bisects, branches,
>>> remotes, hooks, workdir, submodules and all the new development seem
>>> to be done on Git nowadays, not SVN. Windows may be an odd one related
>>> to GUIs, but Visual Studio has Git integration and I hear it's similar
>>> to the other MSVC VCSs. GitHub's desktop interface seems pretty cool,
>>> too.
>>> 
>>> * Web repositories make it *a lot* easier to create add-hoc pull
>>> requests by non-developers, which could boost the number of
>>> contributions and future contributors, as well as external projects
>>> using LLVM components.
>>> 
>>> * GitHub's SVN RW interface has been reported to work well for
>>> simpler projects, but we need a more thorough examination before
>>> declare it good enough for our purposes.
>>> 
>>> * All reports on the thread pointed that downstream infrastructure is
>>> already using Git, so that's one less problem to worry about if we do
>>> move.
>>> 
>>> 
>>>  The issues that were raised:
>>> 
>>> * Co-dependent patches already break buildbots, but the sequential ID
>>> helps us identify and ignore. They will continue to break, even if we
>>> use git sub-modules, so that doesn't change much, but it will be
>>> harder to spot the issue. Server side hooks may help, as well as
>>> sub-modules.
>>> 
>>> * Windows tooling may be an issue. There's a separate thread handling
>>> that part, so I won't cover it here. But I have to say it wasn't by a
>>> long shot a resonant problem. It may also have some problem with
>>> symlinks and in-tree checkouts (when interacting with llvm-projects
>>> and sub-modules).
>>> 
>>> * Sub-modules may help with a lot of the current relationship we have
>>> inside the SVN repo, but it also has some problems. Namely they:
>>> - require a modern version of git (1.7/1.9), but that's 2013 onward.
>>> - may need additional server side scripting, but we can keep that
>>> in another repo to control it.
>>> - won't replace SVN's

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Mehdi Amini via lldb-dev]

> On Jun 2, 2016, at 4:28 PM, Tanya Lattner  wrote:
> 
> 
> 
>> On Jun 2, 2016, at 12:18 PM, Mehdi Amini  wrote:
>> 
>> 
>>> On Jun 2, 2016, at 9:21 AM, Tanya Lattner via llvm-dev 
>>>  wrote:
>>> 
>>> I personally find this email thread very hard to follow and read (this 
>>> isn’t anyones fault.. its just a lot of replies). I am sure others do as 
>>> well. I think it would be good to have a form/survey of some sort that can 
>>> get feedback from users such as: who they are, how they use 
>>> LLVM/contributions/etc,  if they are pro-github move, how it impacts them, 
>>> etc. People could then submit their feedback in an organized way and we 
>>> could get a better idea of how the community feels on the topic. 
>>> 
>>> I am happy to try to set something like this up.
>> 
>> I don't think it is a good idea to set this up like that without having a 
>> well defined plan first.
>> My idea is rather that we should first try to see what is doable in term of 
>> server-side hook and integration so that the "poll" is not about naked "svn 
>> vs git", but about "svn vs 
>> git-with-this-server-side-setup-that-preserve-our-workflow".
>> 
> 
> Sure, I am fine with flushing out those details out. Just an idea to get a 
> better idea of the consensus when the time comes.

We're on the same page.

-- 
Mehdi

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev