[lldb-dev] [Bug 28353] New: TestTopLevelExprs.py fails with gcc-4.8
https://llvm.org/bugs/show_bug.cgi?id=28353 Bug ID: 28353 Summary: TestTopLevelExprs.py fails with gcc-4.8 Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: lab...@google.com CC: llvm-b...@lists.llvm.org Classification: Unclassified == FAIL: test_top_level_expressions_dwarf (TestTopLevelExprs.TopLevelExpressionsTestCase) -- Traceback (most recent call last): File "/usr/local/google/home/labath/ll/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1474, in dwarf_test_method return attrvalue(self) File "/usr/local/google/home/labath/ll/lldb/packages/Python/lldbsuite/test/decorators.py", line 93, in wrapper func(*args, **kwargs) File "/usr/local/google/home/labath/ll/lldb/packages/Python/lldbsuite/test/decorators.py", line 93, in wrapper func(*args, **kwargs) File "/usr/local/google/home/labath/ll/lldb/packages/Python/lldbsuite/test/decorators.py", line 121, in wrapper func(*args, **kwargs) File "/usr/local/google/home/labath/ll/lldb/packages/Python/lldbsuite/test/decorators.py", line 121, in wrapper func(*args, **kwargs) File "/usr/local/google/home/labath/ll/lldb/packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py", line 88, in test_top_level_expressions self.assertEqual(resultFromCode, resultFromTopLevel.GetValueAsUnsigned()) AssertionError: 11L != 0L Config=x86_64-/usr/bin/gcc-4.8 -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 28354] New: TestTemplateIntegerArgs.py fails with gcc
https://llvm.org/bugs/show_bug.cgi?id=28354 Bug ID: 28354 Summary: TestTemplateIntegerArgs.py fails with gcc Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: lab...@google.com CC: llvm-b...@lists.llvm.org Classification: Unclassified == FAIL: test_with_run_command_dwarf (TestTemplateIntegerArgs.TemplateIntegerArgsTestCase) Test that C++ template classes that have integer parameters work correctly. -- Traceback (most recent call last): File "/usr/local/google/home/labath/ll/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1474, in dwarf_test_method return attrvalue(self) File "/usr/local/google/home/labath/ll/lldb/packages/Python/lldbsuite/test/lang/cpp/template/TestTemplateIntegerArgs.py", line 68, in test_with_run_command self.assertTrue(member.GetType().GetName() == 'EnumTemplate') AssertionError: False is not True Config=x86_64-/usr/bin/gcc-4.8 -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Calling multiply defined symbols
Hi all, We have a process that contains multiple definitions of the same function. The function in question is declared 'static extern' in a header and included in multiple compilation units. This causes some confusion for lldb expression parser when trying to invoke the function by name, since it doesn't know which of the multiple (identical) implementations to call. In this case the expression evaluation fails and informs the user 'call to 'abs' is ambiguous' in my case. The function in question could be changed to resolve the error, but I'd be interested to know if there is a way to resolve such an ambiguity from the LLDB's CLI. Alternatively, should there be an precedence order that LLDB could be made to obey in the case of this ambiguity? Thanks, Aidan ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Remote debugging - unix socket and/or specific port
Hi Adrien, I think your diagnosis is correct here. LLDB does indeed create an additional connection to the gdb-server instance which is started by the platform instance when you start debugging. In case of android platforms we already include code to forward this port automatically, but there is no such thing for linux -- we just expect the server to be reachable. Unfortunately, there is no way to control this behavior at the moment. I suppose you could unblock all ports on the container, but make sure that they are only reachable from the host (I know that's not ideal). cheers, pl On 22 June 2016 at 19:18, Adrien Duermael via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi, > > I’ve been trying to run* lldb-server* from within a linux container > lately. > > When I try to attach from outside the container using *lldb *command, > most steps are successful but I can’t launch the process: > > platform select remote-linux 👍 > platform connect connect://IP:PORT 👍 > target create main 👍 > process launch ❌ > > My guess is that the container only exposes the control port, the one I’m > listening to with *lldb-server p --listen *:PORT.* > And it seems that ports are dynamically allocated to then handle process > debugging. > > I don’t want my container to expose too many ports, as I usually have in > fact only one debuggable process running inside. > (I tried, I can launch my process if the container exposes all ports) > > Is there a way to set a range for these dynamically allocated ports using > *lldb-server?* > > I can’t find it in the docs, and help command can’t help me either: > *Usage:* > * lldb-server p [--log-file log-file-name] [--log-channels > log-channel-list] [--port-file port-file-path] --server --listen port* > > Also, is there an option to use unix sockets instead of ports? > > Thanks for your help! > > - Adrien Duermael > > ___ > 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] Git Move: GitHub+modules proposal
Hi all, A short summary: Takumi has done 90% of the work here: https://github.com/llvm-project/llvm-project-submodule and I've been talking to GitHub, and here are the answers to my questions: > 1. How will the umbrella project's auto-increment hook work? Since the umbrella project cannot see the sub-modules' commits without some form of update, there are two ways to do this: P. Per push: Every push (not commit) on all other repositories will trigger a hook that will hit a URL on our server, telling it to generate an incremental ID, update some umbrella's SeqID property (or even a commit SHA) and update the sub-modules. T. Time based: A cron job in our server would frequently pull from all repos and update ID/modules. Option P is less confusion and more fine grained, but if it misfire, we'll lose that push, and its commits will be bundled with the next push on that repo. Option T will invariably bundle things together, even from different repositories. The change that this will "correctly" merge an LLVM+Clang double-patch is not worth the trouble for the noise. For both of them, we need an external server, as there's no way to update a repository's property from another. Multiple commits eventually getting into a single umbrella revision can be innocuous for development, but they can make controlling the version for releases a bit more complicated. Though, it would also have no effect on back-ports, since they'll be done on Git and get their own SeqID. All in all, I'm not too worried about this... > 2. How do we update the commits mailing lists? This is, apparently, trivial in GitHub: https://help.github.com/articles/managing-notifications-for-pushes-to-a-repository/#enabling-email-service-notifications-for-pushes-to-your-repository Any more comments before we put this proposal to vote? Is anyone going to propose an alternative Git solution? Or maybe an external, reliable and trustworthy SVN repository (ie. *not* SourceForge)? In the interests of brevity and peacefulness, we should aim to only have one vote, even if it has multiple choices, so if we have more proposals, please bring them up. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal
On 29 Jun 2016, at 15:03, Renato Golin via llvm-dev wrote: > > Any more comments before we put this proposal to vote? Thank you very much for driving all of this. I just have one quick question: Will existing clones from the LLVM git mirror and / or llvm-mirror on GitHub continue to work by simply switching the remote in the config? 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] Git Move: GitHub+modules proposal
On 6/29/2016 10:03 AM, Renato Golin via cfe-dev wrote: > Since the umbrella project cannot see the sub-modules' commits without > some form of update, there are two ways to do this: > > P. Per push: Every push (not commit) on all other repositories will > trigger a hook that will hit a URL on our server, telling it to > generate an incremental ID, update some umbrella's SeqID property (or > even a commit SHA) and update the sub-modules. How would you coordinate dependent updates to the sub-modules? For example, in the case where someone makes a change to the LLVM sub-module that requires changes to the Clang sub-module? Would there be some way for a developer to push both sets of updates as an atomic update to the umbrella project? It probably doesn't matter often, as long as the updates to both sub-modules are pushed close together in time. Tom. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal
On Mon, Jun 27, 2016 at 12:13 PM, Renato Golin via llvm-dev < llvm-...@lists.llvm.org> wrote: > On 27 June 2016 at 17:03, Rafael Espíndola > wrote: > > I think that trying to create a ordering/rev number between independent > git > > repositories is fundamentally unreliable. > > > > If we want to keep llvm and clang in lock step we should probably > probably > > just have them in the same repository like > > https://github.com/llvm-project/llvm-project. > > That is similar to the proposal we have, except that llvm-projects > will have sub-modules. > > Having all of them in the same physical repository is a big problems > for those that only use a small subset of the components, which is the > vast majority of users, most of the time (all buildbots, Jenkins, > local development, downstream users, even releases don't clone all > repos). (This is kinda a sidenote, because it doesn't actually change the problem-space at all, but :) I really disagree that it'd cause big problems to merge them all. Especially when using git, which makes it a lot easier to keep a local shared copy of the repository, so you don't need to re-download the whole world every time you want a clean checkout. The entire set of llvm code, all put together, is really just not that big in the end. But I do find it annoying to have the many different repositories to track, and I don't really see the value of having as many as we do. However, even without big problems, it does make some sense to keep the C/C++ language separate from the (mostly-)language-independent llvm backend. There are a multitude of other frontends which use LLVM too: go, swift, rust, etc. Would we really want to pull in all of those into a single repo, as well, if they happened to get contributed to the llvm project organization? Probably not. So, while this wouldn't affect the need for a "llvm-project" repository, it might be nice to consider merging some of the other ones together E.g.: llvm: Core language-independent functionality: LLVM, assembler, and linker tools. (merge in lld, and maybe compiler-rt, to the llvm repository). clang: C/C++ frontend and related libraries (merge in clang-tools-extra, libcxx, and libcxxabi into the clang repository). ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Getting the address of a variable
Hi all,
Given a file name, line number and variable name, I am trying to determine the
address. I tried the following approach:
* First I got the block corresponding to the file and line:
o from the file name I got a SBCompileUnit
o using the SBCompileUnit and line number I got a SBLineEntry
? for FindLineEntryIndex the "exact" parameter needs to be false else it will
return empty if the line is on a function
o get the SBBlock: lineEntry.GetStartAddress().GetBlock()
* Now I got the variables for that block and search by name
o block.GetVariables(target, True, True, True)
o I still need to figure out if on the given line there is a function static
and a function argument since both will show up in the list
o Search for the variable by name and get its address - there is no address :(
The problem is that for line 3 in the code below, my SBValue object in the list
doesn't have an address, just "". Any ideas how to solve this?
Also, how can I set the context for evaluating an expression to a file and line
number? (on line 8, evaluate "v" to 1)
1 void foo()
2 {
3 int v = 1;
4 {
5 int v = 2;
--> 6 ++v;
7 }
8 v += 5;
9 }
Thanks,
Bogdan
National Instruments Romania S.R.L.
--
B-dul 21 Decembrie 1989, nr. 77, A2
Cluj-Napoca 400604, Romania
C.I.F.: RO17961616 | O.R.C.: J12/3337/2005
Telefon: +40 264 406428 | Fax: +40 264 406429
E-mail: office.c...@ni.com
Web: romania.ni.com
Vanzari si suport tehnic:
Telefon gratuit : 0800 070071
E-mail vanzari: ni.roma...@ni.com
E-mail suport tehnic: techsupp...@ni.com
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Getting the address of a variable
> On Jun 29, 2016, at 9:51 AM, Bogdan Hopulele via lldb-dev
> wrote:
>
> Hi all,
>
> Given a file name, line number and variable name, I am trying to determine
> the address. I tried the following approach:
> · First I got the block corresponding to the file and line:
> o from the file name I got a SBCompileUnit
> o using the SBCompileUnit and line number I got a SBLineEntry
> § for FindLineEntryIndex the “exact” parameter needs to be false else it
> will return empty if the line is on a function
> o get the SBBlock: lineEntry.GetStartAddress().GetBlock()
> · Now I got the variables for that block and search by name
Any easier way might be to set a breakpoint by file and line. There may be more
than one breakpoint location for a given file and line (inline functions for
example). Once you have a breakpoint you can check the SBAddress of each
location:
lldb::SBBreakpoint bp = target.BreakpointCreateByLocation("main.cpp", 12);
const size_t num_locs = bp.GetNumLocations();
for (size_t i=0; i o block.GetVariables(target, True, True, True)
> o I still need to figure out if on the given line there is a function
> static and a function argument since both will show up in the list
You can ask each SBValue for its lldb::ValueType:
lldb::ValueType
lldb::SBValue::GetValueType ();
enum ValueType
{
eValueTypeInvalid = 0,
eValueTypeVariableGlobal= 1,// globals variable
eValueTypeVariableStatic= 2,// static variable
eValueTypeVariableArgument = 3,// function argument variables
eValueTypeVariableLocal = 4,// function local variables
eValueTypeRegister = 5,// stack frame register value
eValueTypeRegisterSet = 6,// A collection of stack frame
register values
eValueTypeConstResult = 7 // constant result variables
};
> o Search for the variable by name and get its address – there is no address
> L
You can ask each value for its load address with:
lldb::addr_t
lldb::SBValue::GetLoadAddress();
You must be stopped in a stack frame in order for this to work with locals and
arguments. Statics and globals will be able to answer the question _if_ the
module that contains the static/global is loaded into memory in a process that
is running. You can also set make a target and manually set the load locations
of shared libraries (see http://lldb.llvm.org/symbolication.html) and then you
will be able to get addresses for globals/statics.
> The problem is that for line 3 in the code below, my SBValue object in the
> list doesn’t have an address, just “ DW_OP_fbreg opcode.>”. Any ideas how to solve this?
You can't evaluate expressions for local variables unless you are in the stack
frame stopped at that address. Why? Variables say "I am located at the frame
base pointer + 32". So unless you actually are stopped in a stack frame at that
address, you won't be able to know what "frame base pointer" is. This is
typically the RBP register on x86_64, EBP on x86, and FP register on ARM and
ARM64.
>
> Also, how can I set the context for evaluating an expression to a file and
> line number? (on line 8, evaluate “v” to 1)
Again, you really can't set the context because you actually need to be stopped
there so that the CPU registers are all setup and correct. You can just set
breakpoints and run to the needed locations and then evaluate the expressions
when you know where you are stopped so that you know which expressions you will
want to evaluate.
There are two ways to evaluate an expression:
- use a lldb::SBTarget
- use a lldb::SBFrame
If you use the target, you can evaluate an expression for code like:
int g_global = 123;
int main()
{...}
lldb::SBValue global_expr = target.EvaluateExpression("g_global");
Since "g_global" has a value in the .data section, it can be evaluated without
needing a frame and this expression will after you create your target and
before you actually run it because it can read the value of g_global from the
.data section in your executable.
If you use a stack frame, then you are stopped somewhere and are asking the
frame to help evaluate the values of any local and arguments values for the
current function.
Does that make more sense?
> 1 void foo()
> 2 {
> 3 int v = 1;
> 4 {
> 5 int v = 2;
> --> 6 ++v;
> 7 }
> 8 v += 5;
> 9 }
>
> Thanks,
> Bogdan
> National Instruments Romania S.R.L.
> --
> B-dul 21 Decembrie 1989, nr. 77, A2
> Cluj-Napoca 400604, Romania
> C.I.F.: RO17961616 | O.R.C.: J12/3337/2005
> Telefon: +40 264 406428 | Fax: +40 264 406429
> E-mail: office.c...@ni.com
> Web: romania.ni.com
>
> Vanzari si suport tehnic:
> Telefon gratuit : 0800 070071
> E-mail vanzari: ni.roma...@ni.com
> E-mail suport tehnic: techsupp...@ni.com
> ___
Re: [lldb-dev] Calling multiply defined symbols
We have a not-yet-implemented scheme to allow some syntax like: (lldb) expr $$foo.c$bar(5) that would mean: look up the version of bar defined in foo.c and call that. What I wrote above isn't right, since the "." is going to cause the parser headaches, so we'll have to come up with some cleverer way to encode file-names that won't be absolutely horrible to type. That would allow you to by hand disambiguate this sort of name collision. This would also useful for accessing static variables in files & functions. The expression parser does have some precedence order to deal with multiple symbols of the same name. For instance, if there is one version in the dylib containing the current source file and others out in the world, we will pick the one in the containing dylib. If the function is actually implemented in the compilation unit that holds the current frame, we should know to use that one and not the others. We'd have to have debug info to be able to determine this. If that's not working, then that shouldn't be hard to fix.But if there are just a bunch of implementations in the same dylib but not in the current compilation unit, there's no reasonable distance metric to use to determine precedence. Jim > On Jun 29, 2016, at 4:57 AM, Aidan via lldb-dev > wrote: > > Hi all, > > We have a process that contains multiple definitions of the same function. > The function in question is declared 'static extern' in a header and included > in multiple compilation units. > This causes some confusion for lldb expression parser when trying to invoke > the function by name, since it doesn't know which of the multiple (identical) > implementations to call. In this case the expression evaluation fails and > informs the user 'call to 'abs' is ambiguous' in my case. > > The function in question could be changed to resolve the error, but I'd be > interested to know if there is a way to resolve such an ambiguity from the > LLDB's CLI. > Alternatively, should there be an precedence order that LLDB could be made to > obey in the case of this ambiguity? > > Thanks, > Aidan > ___ > 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] Calling multiply defined symbols
Thanks Jim, thats some very helpful information. Sounds like we should take a closer look at our setup to see why the existing precedence is having trouble resolving this for us. Aidan On 29/06/16 18:24, Jim Ingham wrote: We have a not-yet-implemented scheme to allow some syntax like: (lldb) expr $$foo.c$bar(5) that would mean: look up the version of bar defined in foo.c and call that. What I wrote above isn't right, since the "." is going to cause the parser headaches, so we'll have to come up with some cleverer way to encode file-names that won't be absolutely horrible to type. That would allow you to by hand disambiguate this sort of name collision. This would also useful for accessing static variables in files & functions. The expression parser does have some precedence order to deal with multiple symbols of the same name. For instance, if there is one version in the dylib containing the current source file and others out in the world, we will pick the one in the containing dylib. If the function is actually implemented in the compilation unit that holds the current frame, we should know to use that one and not the others. We'd have to have debug info to be able to determine this. If that's not working, then that shouldn't be hard to fix.But if there are just a bunch of implementations in the same dylib but not in the current compilation unit, there's no reasonable distance metric to use to determine precedence. Jim On Jun 29, 2016, at 4:57 AM, Aidan via lldb-dev wrote: Hi all, We have a process that contains multiple definitions of the same function. The function in question is declared 'static extern' in a header and included in multiple compilation units. This causes some confusion for lldb expression parser when trying to invoke the function by name, since it doesn't know which of the multiple (identical) implementations to call. In this case the expression evaluation fails and informs the user 'call to 'abs' is ambiguous' in my case. The function in question could be changed to resolve the error, but I'd be interested to know if there is a way to resolve such an ambiguity from the LLDB's CLI. Alternatively, should there be an precedence order that LLDB could be made to obey in the case of this ambiguity? Thanks, Aidan ___ 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] [llvm-dev] Git Move: GitHub+modules proposal
On Wed, Jun 29, 2016 at 9:28 AM, James Y Knight via llvm-dev < llvm-...@lists.llvm.org> wrote: > On Mon, Jun 27, 2016 at 12:13 PM, Renato Golin via llvm-dev < > llvm-...@lists.llvm.org> wrote: > >> On 27 June 2016 at 17:03, Rafael Espíndola >> wrote: >> > I think that trying to create a ordering/rev number between independent >> git >> > repositories is fundamentally unreliable. >> > >> > If we want to keep llvm and clang in lock step we should probably >> probably >> > just have them in the same repository like >> > https://github.com/llvm-project/llvm-project. >> >> That is similar to the proposal we have, except that llvm-projects >> will have sub-modules. >> >> Having all of them in the same physical repository is a big problems >> for those that only use a small subset of the components, which is the >> vast majority of users, most of the time (all buildbots, Jenkins, >> local development, downstream users, even releases don't clone all >> repos). > > > (This is kinda a sidenote, because it doesn't actually change the > problem-space at all, but :) > > I really disagree that it'd cause big problems to merge them all. > Especially when using git, which makes it a lot easier to keep a local > shared copy of the repository, so you don't need to re-download the whole > world every time you want a clean checkout. The entire set of llvm code, > all put together, is really just not that big in the end. But I do find it > annoying to have the many different repositories to track, and I don't > really see the value of having as many as we do. > This is anecdotal, but using llvm-project on a ~daily basis, I can say that the place where the larger repo is noticeable is the increased size of the checkout; this affects the time of `git status` and many other frequently used commands. It isn't terrible though (even on windows; at least with an SSD; I haven't tried HDD). > > However, even without big problems, it does make some sense to keep the > C/C++ language separate from the (mostly-)language-independent llvm > backend. There are a multitude of other frontends which use LLVM too: go, > swift, rust, etc. Would we really want to pull in all of those into a > single repo, as well, if they happened to get contributed to the llvm > project organization? Probably not. > Clang is special in that we have the expectation that developers need to update clang if their patch to LLVM breaks it. (I assume this is largely due to its role in self-hosting). It is unlikely that any other frontend will ever get that special treatment since it does entail a high maintenance burden. So I don't see a strong reason to split out clang just because it is a "frontend". Roughly speaking, I would prefer a repo division (if any) to be along the lines of "core toolchain" (clang, llvm, lld, compiler-rt) and "extra stuff not strictly required". Just my 2c -- Sean Silva > So, while this wouldn't affect the need for a "llvm-project" repository, > it might be nice to consider merging some of the other ones together > > E.g.: > llvm: Core language-independent functionality: LLVM, assembler, and linker > tools. (merge in lld, and maybe compiler-rt, to the llvm repository). > clang: C/C++ frontend and related libraries (merge in clang-tools-extra, > libcxx, and libcxxabi into the clang repository). > > > > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal
On 29 June 2016 at 15:11, David Chisnall wrote: > Will existing clones from the LLVM git mirror and / or llvm-mirror on GitHub > continue to work by simply switching the remote in the config? I hope so. There isn't anything (modulo mistakes) stopping us from having a clean migration. We'll have to re-organise the GitHub mirrors, though, as Takumi has mostly driven out of his own account, and it'll have to be owned by "The LLVM Project" somehow. Mehdi suggested us to flip the mirror (from GitHub to LLVM Git to SVN), as soon as we mark them read-only, and then open RW only in GitHub. We don't want to use GitHub's "pull requests" for every patch, so we'll have to add push rights to all committers today. Meaning, you can just change the remote to the official GitHub repo and get rid of Git-SVN. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] Git Move: GitHub+modules proposal
On 29 June 2016 at 16:50, Tom Honermann wrote: > How would you coordinate dependent updates to the sub-modules? We won't. Not now. Maybe later. Right now, doing that means changing how we work and we're trying to make the least number of changes at a time. But this is the most requested feature and I'm sure we'll find something that will work as soon as everything is stable. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal
On 29 June 2016 at 19:51, Sean Silva wrote: > Roughly speaking, I would prefer a repo division (if any) to be along the > lines of "core toolchain" (clang, llvm, lld, compiler-rt) and "extra stuff > not strictly required". The problem comes when different people consider "core" different projects. :) We're always reviewing the projects and we do split them when people agree it's needed. Examples are the libunwind coming out of Compiler-RT, and the recent discussion to do the same with the sanitizers and others. This is not just about preference, but it's about cross dependency, and the only sane way we can cross-build to multiple targets. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal
On Wed, Jun 29, 2016 at 12:04 PM, Renato Golin wrote: > On 29 June 2016 at 19:51, Sean Silva wrote: > > Roughly speaking, I would prefer a repo division (if any) to be along the > > lines of "core toolchain" (clang, llvm, lld, compiler-rt) and "extra > stuff > > not strictly required". > > The problem comes when different people consider "core" different > projects. :) > Sure. But selfhost (incl. stuff like selfhost w/ sanitizers) is a fairly important special case we may be able to agree on. (and I say this as somebody that largely builds cross-compilers (targeting PS4)) -- Sean Silva > > We're always reviewing the projects and we do split them when people > agree it's needed. > > Examples are the libunwind coming out of Compiler-RT, and the recent > discussion to do the same with the sanitizers and others. This is not > just about preference, but it's about cross dependency, and the only > sane way we can cross-build to multiple targets. > > cheers, > --renato > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal
On 29 June 2016 at 20:14, Sean Silva wrote: > Sure. But selfhost (incl. stuff like selfhost w/ sanitizers) is a fairly > important special case we may be able to agree on. (and I say this as > somebody that largely builds cross-compilers (targeting PS4)) In that case, RT wouldn't "have" to be core. We use GCC rt-libs on GNU systems, even for self-hosting. Even if we move to full RT builtins (which I really want), we'd have to get rid of everything else in that repo to move it to core. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal
On Wed, Jun 29, 2016 at 12:18 PM, Renato Golin wrote: > On 29 June 2016 at 20:14, Sean Silva wrote: > > Sure. But selfhost (incl. stuff like selfhost w/ sanitizers) is a fairly > > important special case we may be able to agree on. (and I say this as > > somebody that largely builds cross-compilers (targeting PS4)) > > In that case, RT wouldn't "have" to be core. We use GCC rt-libs on GNU > systems, even for self-hosting. > I think there is a compelling argument for selfhosting with sanitizers (the sanitizer bootstrap bot has saved me more times than I care to admit). -- Sean Silva > > Even if we move to full RT builtins (which I really want), we'd have > to get rid of everything else in that repo to move it to core. > > cheers, > --renato > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal
On Wed, Jun 29, 2016 at 12:34 PM, Sean Silva wrote: > > > On Wed, Jun 29, 2016 at 12:18 PM, Renato Golin > wrote: > >> On 29 June 2016 at 20:14, Sean Silva wrote: >> > Sure. But selfhost (incl. stuff like selfhost w/ sanitizers) is a fairly >> > important special case we may be able to agree on. (and I say this as >> > somebody that largely builds cross-compilers (targeting PS4)) >> >> In that case, RT wouldn't "have" to be core. We use GCC rt-libs on GNU >> systems, even for self-hosting. >> > > I think there is a compelling argument for selfhosting with sanitizers > (the sanitizer bootstrap bot has saved me more times than I care to admit). > Also libprofile for PGO selfhost. -- Sean Silva > > -- Sean Silva > > >> >> Even if we move to full RT builtins (which I really want), we'd have >> to get rid of everything else in that repo to move it to core. >> >> cheers, >> --renato >> > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Problem of building lldb on Mac
Nevermind, I was finally unable to build by "git pull" and "xcodebuild -configuration Debug" On Mon, Jun 27, 2016 at 9:55 PM, Jeffrey Tan wrote: > Hi, > > I followed instructions in http://lldb.llvm.org/build.html to build lldb > on Mac. > > I opened "*lldb/lldb.xcworkspace*" in Xcode7.3.1, select lldb-tools > scheme and build, I always got build error below. I have tried "brew > install cmake" but the installed cmake version does not match what build > script is looking for. > > *Questions:* > Do I suppose to find and download 3.1.2 version of cmake to get this > working? Do I miss anything? Thanks. > > ... > > /bin/sh -c > /Users/jeffreytan/Library/Developer/Xcode/DerivedData/lldb-acenblzastrxbocknmwzltsmlasq/Build/Intermediates/lldb.build/DebugClang/lldb-core.build/Script-261EECA21337D399001D193C.sh > > > [0/1] Re-running CMake... > > /bin/sh: /usr/local/Cellar/cmake/3.1.2/bin/cmake: No such file or directory > > FAILED: build.ninja > > /usr/local/Cellar/cmake/3.1.2/bin/cmake > -H/Users/jeffreytan/local/lldb/llvm > -B/Users/jeffreytan/local/lldb/llvm-build/Debug+Asserts/x86_64 > > ninja: error: rebuilding 'build.ninja': subcommand failed > > Traceback (most recent call last): > > File "/Users/jeffreytan/local/lldb/scripts/Xcode/build-llvm.py", line > 340, in > > build_llvm_if_needed() > > File "/Users/jeffreytan/local/lldb/scripts/Xcode/build-llvm.py", line > 334, in build_llvm_if_needed > > build_llvm(ninja_binary_path) > > File "/Users/jeffreytan/local/lldb/scripts/Xcode/build-llvm.py", line > 328, in build_llvm > > subprocess.check_call([ninja_binary_path], cwd=cmake_build_dir, > env=cmake_environment()) > > File > "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", > line 540, in check_call > > raise CalledProcessError(retcode, cmd) > > subprocess.CalledProcessError: Command > '['/Users/jeffreytan/local/lldb/ninja/ninja']' returned non-zero exit > status 1 > > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [3.9 Release] Release plan and call for testers
On Fri, Jun 10, 2016 at 1:38 PM, Hans Wennborg wrote: > 2) Following up on the May thread about the release process [1], I'd > like to make the schedule we've followed for the last few years more > official by posting somewhere on the web page that we're committed to > shipping two major releases per year: one in early March (branching > mid-January), and one early September (branching mid-July), usually > with one (or sometimes two) "dot" releases in between. > > 3) Another follow-up from that thread: it's usually the same people > who test the releases for their platform. Rather than asking everyone > each time, I'd like to make a list of who's responsible for each > platform and put that on the web page. Testers can still sign-up or > resign as they like, of course. Would you testers be OK with this? I've sent out a patch to update the docs for this: http://reviews.llvm.org/D21880 Please take a look. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal
> On Jun 29, 2016, at 10:03 AM, Renato Golin via llvm-dev > wrote: > > Hi all, > > A short summary: Takumi has done 90% of the work here: > > https://github.com/llvm-project/llvm-project-submodule > > and I've been talking to GitHub, and here are the answers to my questions: > > >> 1. How will the umbrella project's auto-increment hook work? > > Since the umbrella project cannot see the sub-modules' commits without > some form of update, there are two ways to do this: > > P. Per push: Every push (not commit) on all other repositories will > trigger a hook that will hit a URL on our server, telling it to > generate an incremental ID, update some umbrella's SeqID property (or > even a commit SHA) and update the sub-modules. > > T. Time based: A cron job in our server would frequently pull from all > repos and update ID/modules. > > Option P is less confusion and more fine grained, but if it misfire, > we'll lose that push, and its commits will be bundled with the next > push on that repo. > > Option T will invariably bundle things together, even from different > repositories. The change that this will "correctly" merge an > LLVM+Clang double-patch is not worth the trouble for the noise. > > For both of them, we need an external server, as there's no way to > update a repository's property from another. That makes it fragile, and that’s why I disagree with your “90% done” assessment. What if the service behing the hook is down for a few days? Who will maintain it? — Mehdi > > Multiple commits eventually getting into a single umbrella revision > can be innocuous for development, but they can make controlling the > version for releases a bit more complicated. Though, it would also > have no effect on back-ports, since they'll be done on Git and get > their own SeqID. > > All in all, I'm not too worried about this... > > >> 2. How do we update the commits mailing lists? > > This is, apparently, trivial in GitHub: > > https://help.github.com/articles/managing-notifications-for-pushes-to-a-repository/#enabling-email-service-notifications-for-pushes-to-your-repository > > Any more comments before we put this proposal to vote? > > Is anyone going to propose an alternative Git solution? > > Or maybe an external, reliable and trustworthy SVN repository (ie. > *not* SourceForge)? > > In the interests of brevity and peacefulness, we should aim to only > have one vote, even if it has multiple choices, so if we have more > proposals, please bring them up. > > cheers, > --renato > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal
> That makes it fragile, and that’s why I disagree with your “90% done” > assessment. > What if the service behing the hook is down for a few days? In the long-term view, a pretty trivial catch-up script ought to be able to synthesize a sane history after any amount of down-time. People could even run it locally for their bisecting needs if it was that important to them. In the short term, I don't think it's a critical enough service to worry about, frankly. What we already have is hopelessly fragile: right now when LLVM's server plays up it takes out absolutely everything, in the proposed world it would take out this bisecting convenience feature. Seems like a strict improvement to me. > Who will maintain it? I'm not the best scripter and I'd be happy to cede to someone else, but I'd be willing if it meant we could make progress. Tim. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
