On 3 June 2016 at 06:39, Jeremy Lakeman wrote:
> For example;
> write a new feature as a series of patches against both llvm & clang
> open a pull request
> somebody pushes some "approval" button (in Phabricator?)
> both patch series are rebased onto llvm & clang's TOT
> a single commit is created
Hi everyone
While debugging an inferior with LLDB, for every stop event a new StopID is
generated and this ID can be extracted from SBProcess::GetStopID() API.
This ID indicates change in the state of the process between two stop
events.
As per my knowledge, in case of a multithreaded process thi
On Thu, Jun 2, 2016 at 9:58 PM, Jason Molenda wrote:
> This has no eh_frame unwind instructions. Even if we were using eh_frame
> at frame 0, you'd be out of luck.
>
I did not understand how eh_frame unwind instructions are not there,
pardon me asking, can you tell me how you inferred that
> On Jun 3, 2016, at 2:22 AM, Abhishek Aggarwal via lldb-dev
> wrote:
>
> Hi everyone
>
> While debugging an inferior with LLDB, for every stop event a new StopID is
> generated and this ID can be extracted from SBProcess::GetStopID() API. This
> ID indicates change in the state of the proce
Note that we do know when we've actively suspended threads, but in an average
step, you will spend a fair bit of the time allowing all threads to run. So
that wouldn't allow a very accurate accounting.
Jim
> On Jun 3, 2016, at 8:42 AM, Jim Ingham via lldb-dev
> wrote:
>
>
>> On Jun 3, 201
On Fri, Jun 3, 2016 at 1:18 AM, Renato Golin via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> 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, s
On Thu, Jun 2, 2016 at 2:43 PM, Aaron Ballman via cfe-dev wrote:
>
> Some developers on Windows prefer to use GUI tools like TortoiseSVN to
> command line tools for version control.
(snip)
> Are there suitable GUI tools for git on Windows for projects as
> complex as LLVM? I believe MSVC has som
On Jun 2, 2016, at 11:01 AM, d...@cray.com wrote:
>
> 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 th
> On Jun 2, 2016, at 11:42 AM, via lldb-dev wrote:
>
> 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 d
