Re: [lldb-dev] [llvm-dev] GitHub anyone?
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 in the master repo, capturing how the llvm & > clang submodules jumped from the commit before my patches, to the last > commit in each series. Can't you generate a unique ID for each submodule commit? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Stop IDs for individual thread
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 this stop ID can't be used to exactly pin point the thread(s) of the process that suffered change in their states between two stop events. Is there a way to find out this information? - Abhishek ___ 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
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 ?
>
> 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.
>
> The unwind plan for the first row in the assembly unwinder is wrong,
> its off by 2 bytes I don't know why it is so but the root cause of failure
> for TestPrintStackTraces is this, since it uses the assembly unwinder, its
> not able to unwind correctly and the eh_frame based info is actually
> correct. I did verify that when the eh_frame info is used, the stack
> unwinding is correct in this case.
> 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 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]:
Re: [lldb-dev] Stop IDs for individual thread
> 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 process between two stop events. > > As per my knowledge, in case of a multithreaded process this stop ID can't be > used to exactly pin point the thread(s) of the process that suffered change > in their states between two stop events. Is there a way to find out this > information? That's not something the debugger tracks actively - when the process is running we try to interfere with it as little as possible. But on systems that have a way of getting per thread activity accounting, you could keep track of that information each time we stop and use that information to figure this out. debugserver on OS X does some reporting of CPU activity, but I don't think that is per thread. You can fetch that with Process::GetAsyncProfileData(), but at present that's just a pass-through (used by Xcode), lldb itself doesn't do anything with this information. Jim > > - Abhishek > ___ > 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] Stop IDs for individual thread
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, 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 process between two stop events. >> >> As per my knowledge, in case of a multithreaded process this stop ID can't >> be used to exactly pin point the thread(s) of the process that suffered >> change in their states between two stop events. Is there a way to find out >> this information? > > That's not something the debugger tracks actively - when the process is > running we try to interfere with it as little as possible. But on systems > that have a way of getting per thread activity accounting, you could keep > track of that information each time we stop and use that information to > figure this out. > > debugserver on OS X does some reporting of CPU activity, but I don't think > that is per thread. You can fetch that with Process::GetAsyncProfileData(), > but at present that's just a pass-through (used by Xcode), lldb itself > doesn't do anything with this information. > > Jim > >> >> - Abhishek >> ___ >> 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 ___ 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?
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, 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. > So as I understand it, there will be a master repository with it's own commit history. Each commit in this repo should be automatically generated as a consistent snapshot of all sub-projects after they have passed build-bot smoke tests. No matter how this master repo is maintained, I'm fairly certain we can make sure that this doesn't become an issue in practice. > >- 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). > > This master repo could replicate svn's ID's. I mean if the commits are created by a bot / script, each commit message could automatically include `git rev-list --count`+1. Note however that each subproject might have more than one commit in their history between the commits in the master repo. 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 in the master repo, capturing how the llvm & clang submodules jumped from the commit before my patches, to the last commit in each series. ___ 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?)
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 some integration, but I've not > used it before. Perhaps other tools exist that match the integration > and stability that TortoiseSVN has with Explorer? Eclipse has a git plugin (included by default in "Eclipse IDE for C++ developers"), although using Eclipse only for git operations seems a bit heavy. I haven't used it for anything beyond "git pull". Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds ___ 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?
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 that's what people want, I don't > know. We certainly haven't missed them since moving to git. I think we *want* to severely limit how history is allowed to look. We don’t want the entire development history of your long-lived branch coming to mainline. When a patch is accepted to an llvm.org repository, it is committed as an atomic unit. It is expected to be reviewed (pre or post), include testcases, and uphold the standards of the project *in that unit*. There is no value in providing additional details. If there were, then the patch should be committed as a linear series of independent pieces, each of which lives up to the project’s standards. -Chris ___ 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?
> 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 development to a release. Some of those > options break linear history. This is the kind of workflow stuff we > should clarify if possible. +1 for branching for official llvm.org releases, and each branch should have its own linear history (from its branch point). I don’t think we want people’s random projects and development branches on llvm.org. They can clone to repo off to their own fork on github and do what they want there. -Chris ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
