[lldb-dev] Final Result - GitHub Survey
Folks, It's been one week after the initial results were shared and three days after the last answer, so I think it's time to close down and publish the final results. The ODF, XLS and CSV files are at: http://people.linaro.org/~renato.golin/LLVM%20Move%20to%20GitHub.zip The overall result is the same, and it's still in sync with what was discussed on the BoF session and I reported back last week: GitHub, not only Git, still has a massive support and the split between mono/multi repo still exists and need to be sorted out. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] A problem with the arm64 unwind plans I'm looking at
Based on your comments I have one more idea for a good heuristic. What if
we detect a dynamic branch (e.g. "br ", "tbb ...", etc...) and store
the register state for that place. Then when we find a block with no unwind
info for the first instruction then we use the one we saved for the dynamic
branch (as we know that the only way that block can be reached is through a
dynamic branch). If there is exactly 1 dynamic branch in the code then this
should gave us the "perfect" result while if we have multiple dynamic
branches then we will pick one "randomly" but for compiler generated code I
think it will be good enough. The only tricky case is if we fail to detect
the dynamic branch but that should be easy to fix as we already track every
branch on ARM (for single stepping) and doing it on AArch64 should be easy
as well.
On Tue, Nov 8, 2016 at 11:10 PM Jason Molenda wrote:
> Yeah I was thinking that maybe if we spot an epilogue instruction (ret, b
> ), and the next instruction doesn't have a reinstated
> register context, we could backtrack to the initial register context of
> this block of instructions (and if it's not the beginning of the function),
> re-instate that register context for the next instruction.
>
> It doesn't help if we have a dynamic dispatch after the initial part of
> the function. For that, we'd need to do something like your suggestion of
> finding the biggest collection of register saves.
>
> e.g. if I rearrange/modify my example function a little to make it more
> interesting (I didn't fix up the +offsets)
>
> prologue:
> > 0x17df0 <+0>: stpx22, x21, [sp, #-0x30]!
> > 0x17df4 <+4>: stpx20, x19, [sp, #0x10]
> > 0x17df8 <+8>: stpx29, x30, [sp, #0x20]
> > 0x17dfc <+12>: addx29, sp, #0x20; =0x20
>
> direct branch:
> > 0x17e1c <+44>: cmpw20, #0x1d; =0x1d
> > 0x17e20 <+48>: b.hi 0x17e4c ; <+92> {
> block #3 }
>
> dynamic dispatch:
> > 0x17e24 <+52>: adrx9, #0x90 ; switcher + 196
> > 0x17e28 <+56>: nop
> > 0x17e2c <+60>: ldrsw x8, [x9, x8, lsl #2]
> > 0x17e30 <+64>: addx8, x8, x9
> > 0x17e34 <+68>: br x8
>
> block #1
> > 0x17e9c <+172>: sxtw x8, w19
> > 0x17ea0 <+176>: strx8, [sp]
> > 0x17ea4 <+180>: adrx0, #0x10f; "%c\n"
> > 0x17ea8 <+184>: nop
> > 0x17eac <+188>: bl 0x17f64 ; symbol stub
> for: printf
> > 0x17e70 <+128>: subsp, x29, #0x20; =0x20
> > 0x17e74 <+132>: ldpx29, x30, [sp, #0x20]
> > 0x17e78 <+136>: ldpx20, x19, [sp, #0x10]
> > 0x17e7c <+140>: ldpx22, x21, [sp], #0x30
> > 0x17eb0 <+192>: b 0x17f4c ; symbol stub
> for: abort
>
> block #2
> > 0x17e38 <+72>: subsp, x29, #0x20; =0x20
> > 0x17e3c <+76>: ldpx29, x30, [sp, #0x20]
> > 0x17e40 <+80>: ldpx20, x19, [sp, #0x10]
> > 0x17e44 <+84>: ldpx22, x21, [sp], #0x30
> > 0x17e48 <+88>: ret
>
>
> block #3
> > 0x17e4c <+92>: addw0, w0, #0x1 ; =0x1
> > 0x17e50 <+96>: b 0x17e38 ; <+72> at
> a.c:115
> > 0x17e54 <+100>: orrw8, wzr, #0x7
> > 0x17e58 <+104>: strx8, [sp, #0x8]
> > 0x17e5c <+108>: sxtw x8, w19
> > 0x17e60 <+112>: strx8, [sp]
> > 0x17e64 <+116>: adrx0, #0x148; "%c %d\n"
> > 0x17e68 <+120>: nop
> > 0x17e6c <+124>: bl 0x17f64 ; symbol stub
> for: printf
> > 0x17e70 <+128>: subsp, x29, #0x20; =0x20
> > 0x17e74 <+132>: ldpx29, x30, [sp, #0x20]
> > 0x17e78 <+136>: ldpx20, x19, [sp, #0x10]
> > 0x17e7c <+140>: ldpx22, x21, [sp], #0x30
> > 0x17e80 <+144>: b 0x17f38 ; f3 at b.c:4
>
> block #4
> > 0x17e38 <+72>: subsp, x29, #0x20; =0x20
> > 0x17e3c <+76>: ldpx29, x30, [sp, #0x20]
> > 0x17e40 <+80>: ldpx20, x19, [sp, #0x10]
> > 0x17e44 <+84>: ldpx22, x21, [sp], #0x30
> > 0x17e48 <+88>: ret
>
> First, an easy one: When we get to the first instruction of 'block #4',
> we've seen a complete epilogue ending in 'B other-function' and the first
> instruction of block #4 is not branched to. If we find the previous direct
> branch target -- to the first instruction of 'block #3' was conditionally
> branched to, we reuse that register context for block #4. This could
> easily go wrong for hand-written assembly where you might undo the stack
> state part-way and then branch to another part of the function. But I
> doubt compiler generated code is ever going to do that.
>
> Second, a trickier one: When we get to the first instruction of 'block
> #2', we have no previous branch t
[lldb-dev] LLVM Social - Paris: November 22nd, 2016
The next LLVM social in Paris will happen on November 22nd, 2016. Everyone interested in LLVM, Clang, lldb, Polly, lld, ... is invited to join. We are looking for volunteers to present (~20 minutes) at this meetup --- as well as the next ones. This does not have to be a formal presentation: this could be a tutorial, a BoF, a bugfix party, your usage of LLVM, ... Be creative ! If interested, please talk to one of the organizers. Event details, including registration (free but mandatory) at http://www.meetup.com/LLVM-Clang-social Looking forward to meet you, -- Arnaud de Grandmaison, Duncan Sands, Sylvestre Ledru ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] A problem with the arm64 unwind plans I'm looking at
I like that idea. A bunch of other work just landed on my desk so it might be
a bit before I do it, but I'll see how that patch looks.
> On Nov 9, 2016, at 3:54 AM, Tamas Berghammer wrote:
>
> Based on your comments I have one more idea for a good heuristic. What if we
> detect a dynamic branch (e.g. "br ", "tbb ...", etc...) and store the
> register state for that place. Then when we find a block with no unwind info
> for the first instruction then we use the one we saved for the dynamic branch
> (as we know that the only way that block can be reached is through a dynamic
> branch). If there is exactly 1 dynamic branch in the code then this should
> gave us the "perfect" result while if we have multiple dynamic branches then
> we will pick one "randomly" but for compiler generated code I think it will
> be good enough. The only tricky case is if we fail to detect the dynamic
> branch but that should be easy to fix as we already track every branch on ARM
> (for single stepping) and doing it on AArch64 should be easy as well.
>
> On Tue, Nov 8, 2016 at 11:10 PM Jason Molenda wrote:
> Yeah I was thinking that maybe if we spot an epilogue instruction (ret, b
> ), and the next instruction doesn't have a reinstated
> register context, we could backtrack to the initial register context of this
> block of instructions (and if it's not the beginning of the function),
> re-instate that register context for the next instruction.
>
> It doesn't help if we have a dynamic dispatch after the initial part of the
> function. For that, we'd need to do something like your suggestion of
> finding the biggest collection of register saves.
>
> e.g. if I rearrange/modify my example function a little to make it more
> interesting (I didn't fix up the +offsets)
>
> prologue:
> > 0x17df0 <+0>: stpx22, x21, [sp, #-0x30]!
> > 0x17df4 <+4>: stpx20, x19, [sp, #0x10]
> > 0x17df8 <+8>: stpx29, x30, [sp, #0x20]
> > 0x17dfc <+12>: addx29, sp, #0x20; =0x20
>
> direct branch:
> > 0x17e1c <+44>: cmpw20, #0x1d; =0x1d
> > 0x17e20 <+48>: b.hi 0x17e4c ; <+92> { block
> > #3 }
>
> dynamic dispatch:
> > 0x17e24 <+52>: adrx9, #0x90 ; switcher + 196
> > 0x17e28 <+56>: nop
> > 0x17e2c <+60>: ldrsw x8, [x9, x8, lsl #2]
> > 0x17e30 <+64>: addx8, x8, x9
> > 0x17e34 <+68>: br x8
>
> block #1
> > 0x17e9c <+172>: sxtw x8, w19
> > 0x17ea0 <+176>: strx8, [sp]
> > 0x17ea4 <+180>: adrx0, #0x10f; "%c\n"
> > 0x17ea8 <+184>: nop
> > 0x17eac <+188>: bl 0x17f64 ; symbol stub for:
> > printf
> > 0x17e70 <+128>: subsp, x29, #0x20; =0x20
> > 0x17e74 <+132>: ldpx29, x30, [sp, #0x20]
> > 0x17e78 <+136>: ldpx20, x19, [sp, #0x10]
> > 0x17e7c <+140>: ldpx22, x21, [sp], #0x30
> > 0x17eb0 <+192>: b 0x17f4c ; symbol stub for:
> > abort
>
> block #2
> > 0x17e38 <+72>: subsp, x29, #0x20; =0x20
> > 0x17e3c <+76>: ldpx29, x30, [sp, #0x20]
> > 0x17e40 <+80>: ldpx20, x19, [sp, #0x10]
> > 0x17e44 <+84>: ldpx22, x21, [sp], #0x30
> > 0x17e48 <+88>: ret
>
>
> block #3
> > 0x17e4c <+92>: addw0, w0, #0x1 ; =0x1
> > 0x17e50 <+96>: b 0x17e38 ; <+72> at a.c:115
> > 0x17e54 <+100>: orrw8, wzr, #0x7
> > 0x17e58 <+104>: strx8, [sp, #0x8]
> > 0x17e5c <+108>: sxtw x8, w19
> > 0x17e60 <+112>: strx8, [sp]
> > 0x17e64 <+116>: adrx0, #0x148; "%c %d\n"
> > 0x17e68 <+120>: nop
> > 0x17e6c <+124>: bl 0x17f64 ; symbol stub for:
> > printf
> > 0x17e70 <+128>: subsp, x29, #0x20; =0x20
> > 0x17e74 <+132>: ldpx29, x30, [sp, #0x20]
> > 0x17e78 <+136>: ldpx20, x19, [sp, #0x10]
> > 0x17e7c <+140>: ldpx22, x21, [sp], #0x30
> > 0x17e80 <+144>: b 0x17f38 ; f3 at b.c:4
>
> block #4
> > 0x17e38 <+72>: subsp, x29, #0x20; =0x20
> > 0x17e3c <+76>: ldpx29, x30, [sp, #0x20]
> > 0x17e40 <+80>: ldpx20, x19, [sp, #0x10]
> > 0x17e44 <+84>: ldpx22, x21, [sp], #0x30
> > 0x17e48 <+88>: ret
>
> First, an easy one: When we get to the first instruction of 'block #4',
> we've seen a complete epilogue ending in 'B other-function' and the first
> instruction of block #4 is not branched to. If we find the previous direct
> branch target -- to the first instruction of 'block #3' was conditionally
> branched to, we reuse that register context for block #4. This could easily
> go wrong for hand-written assembly where yo
[lldb-dev] [Bug 30969] New: Merge r283728 into 3.9 branch.
https://llvm.org/bugs/show_bug.cgi?id=30969 Bug ID: 30969 Summary: Merge r283728 into 3.9 branch. Product: lldb Version: 3.9 Hardware: PC OS: Linux Status: ASSIGNED Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: nitesh.j...@imgtec.com CC: llvm-b...@lists.llvm.org Blocks: 30261 Classification: Unclassified -- 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 30970] New: Merge r283729 into 3.9 branch
https://llvm.org/bugs/show_bug.cgi?id=30970 Bug ID: 30970 Summary: Merge r283729 into 3.9 branch Product: lldb Version: 3.9 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: nitesh.j...@imgtec.com CC: llvm-b...@lists.llvm.org, tstel...@gmail.com Blocks: 30261 Classification: Unclassified -- 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 30971] New: Merge r284003 into 3.9 branch
https://llvm.org/bugs/show_bug.cgi?id=30971 Bug ID: 30971 Summary: Merge r284003 into 3.9 branch Product: lldb Version: 3.9 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: nitesh.j...@imgtec.com CC: llvm-b...@lists.llvm.org, tstel...@gmail.com Blocks: 30261 Classification: Unclassified -- 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 30972] New: Merge r284001 into 3.9 branch
https://llvm.org/bugs/show_bug.cgi?id=30972 Bug ID: 30972 Summary: Merge r284001 into 3.9 branch Product: lldb Version: 3.9 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: nitesh.j...@imgtec.com CC: llvm-b...@lists.llvm.org, tstel...@gmail.com Blocks: 30261 Classification: Unclassified -- 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
