[Lldb-commits] [PATCH] Profile Assembly Until Ret Instruction
Tong Shen
endlessroad at google.com
Tue Aug 19 16:36:53 PDT 2014
Ahh sorry I've been working on something else this week and didn't get back
to you in time.
And you've been very patient and informative. Thanks!
I'm only suggesting it for x86 / x86_64. What I am doing here relies on:
- Compiler describes prologue;
- We can figure our all mid function CFA changes by inspecting instructions.
For frame 0, the new progress for CFA locating will look like this:
- Find the nearest CFI available before current PC.
- If the CFI is for current PC, viola :-) If not, continue.
- Inspect all instructions in between, and make changes to CFA accordingly.
This can solve the PC relative addressing case.
- For epilogue, detect if we are in middle of an epilogue. Considering that
there are not many patterns and they are all simple, I think we can
enumerate them and handle accordingly.
>From what I've seen so far, this actually can solve most of gcc/clang
generated code.
For JIT'ed code or hand written assembly, if there's no asynchronous CFI we
are screwed anyway, so trying this won't hurt either (except some extra
running time).\
I hope I explain my thoughts clearly.
Thank you.
On Tue, Aug 19, 2014 at 4:22 PM, Jason Molenda <jmolenda at apple.com> wrote:
> Hi Tong, my message was a little rambling. Let's be specific.
>
> We are changing lldb to trust eh_frame instructions on the
> currently-executing aka 0th frame.
>
> In practice, gcc and clang eh_frame both describe the prologue, so this is
> OK.
>
> Old gcc and clang eh_frame do not describe the epilogue. So we need to
> add a pass for i386/x86_64 (at least) to augment the eh_frame-sourced
> unwind instructions. I don't know if it would be best to augment eh_frame
> UnwindPlans when we create them in DWARFCallFrameInfo or if it would be
> better to do it lazily when we are actually using the unwind instructions
> in RegisterContextLLDB (probably RegisterContextLLDB like you were doing).
> We should only do it once for a given function, of course.
>
> I think it would cleanest if the augmentation function lived in the
> UnwindAssembly class. But I haven't looked how easy it is to get an
> UnwindAssembly object where we need it.
>
>
> Thanks for taking this on. It will be interesting to try living entirely
> off eh_frame and see how that works for all the architectures/environments
> lldb supports.
>
> I worry a little that we're depending on the generous eh_frame from
> clang/gcc and if we try to run on icc (Intel's compiler) or something like
> that, we may have no prologue instructions and stepping will work very
> poorly. But we'll cross that bridge when we get to it.
>
>
>
> > On Aug 15, 2014, at 8:07 PM, Jason Molenda <jmolenda at apple.com> wrote:
> >
> > Hi Tong, sorry for the delay in replying.
> >
> > I have a couple thoughts about the patch. First, the change in
> RegisterContextLLDB::GetFullUnwindPlanForFrame() forces the use of eh_frame
> unwind instructions ("UnwindPlanAtCallSite" - which normally means the
> eh_frame unwind instructions) for the currently-executing aka zeroth
> frame. We've talked about this before, but it's worth noting that this
> patch includes that change.
> >
> > There's still the problem of detecting how *asynchronous* those eh_frame
> unwind instructions are. For instance, what do you get for an i386 program
> that does
> >
> > #include <stdio.h>
> > int main()
> > {
> > puts ("HI");
> > }
> >
> > Most codegen will use a sequence like
> >
> > call LNextInstruction
> > .LNextInstruction
> > pop ebx
> >
> > this call & pop sequence is establishing the "pic base", it the program
> will then use that address to find the "HI" constant data. If you compile
> this -fomit-frame-pointer, so we have to use the stack pointer to find the
> CFA, do the eh_frame instructions describe this?
> >
> > It's a bit of an extreme example but it's one of those tricky cases
> where asynchronous ("accurate at every instruction") unwind instructions
> and synchronous ("accurate at places where we can throw an exception, or a
> callee can throw an exception") unwind instructions are different.
> >
> >
> > I would use behaves_like_zeroth_frame instead of if (IsFrameZero())
> because you can have a frame in the middle of the stack which was the
> zeroth frame when an asynchronous signal came in -- in which case, the
> "callee" stack frame will be sigtramp.
> >
> >
> > You'd want to update the UnwindLogMsgVerbose() text, of course.
> >
> >
> > What your DWARFCallFrameInfo::PatchUnwindPlanForX86() function is doing
> is assuming that the unwind plan fails to include an epilogue description,
> steps through all the instructions in the function looking for the epilogue.
> >
> > DWARFCallFrameInfo doesn't seem like the right place for this. There's
> an assumption that the instructions came from eh_frame and that they are
> incomplete. It seems like it would more naturally live in the
> UnwindAssembly plugin and it would have a name like
> AugmentIncompleteUnwindPlanWithEpilogue or something like that.
> >
> > What if the CFI already does describe the epilogue? I imagine we'll
> just end up with a doubling of UnwindPlan Rows that describe the epilogue
> instructions.
> >
> > What if we have a mid-function epilogue? I've never seen gcc/clang
> generate these for x86, but it's possible. It's a common code sequence on
> arm/arm64. You can see a messy bit of code in
> UnwindAssemblyInstEmulation::GetNonCallSiteUnwindPlanFromAssembly which
> handles these -- saving the UnwindPlan's unwind instructions when we see
> the beginning of an epilogue, and once the epilogue is complete, restoring
> the unwind instructions.
> >
> >
> > I'm not opposed to the patch - but it does make the assumption that
> we're going to use eh_frame for the currently executing function and that
> the eh_frame instructions do not include a description of the epilogue.
> (and that there is only one epilogue in the function). Mostly I want to
> call all of those aspects out so we're clear what we're talking about
> here. Let's clean it up a bit, put it in and see how it goes.
> >
> > J
> >
> >
> >> On Aug 14, 2014, at 6:31 PM, Tong Shen <endlessroad at google.com> wrote:
> >>
> >> Hi Jason,
> >>
> >> Turns out we still need CFI for frame 0 in certain situations...
> >>
> >> A possible approach is to disassemble machine code, and manually adjust
> CFI for frame 0. For example, if we see "pop ebp; => ret", we set cfa to
> [esp]; if we see "call next-insn; => pop %ebp", we set cfa_offset+=4.
> >>
> >> Patch attached, now it just implements adjustment for "pop ebp; ret".
> >>
> >> If you think this approach is OK, I will go ahead and add other
> tricks(i386 pc relative addressing, more styles of epilogue, etc).
> >>
> >> Thank you for your time!
> >>
> >>
> >> On Thu, Jul 31, 2014 at 12:50 PM, Tong Shen <endlessroad at google.com>
> wrote:
> >> I think gdb's rationale for using CFI for leaf function is:
> >> - gcc always generate CFI for progolue, so at function entry, we know
> the correct CFA;
> >> - any stack pointer altering operation after that(mid-function &
> epilogue), we can recognize and handle them.
> >> So basically, it assumes 2, hacks its way through 3 & 4, and pretends
> we are at 5.
> >> Number of hacks we need seems to be small in x86 world, so this
> tradition is still here.
> >>
> >> Here's what gdb does for epilogue: normally when you run 'n', it will
> run one instruction a time till the next line/different stack id. But when
> it sees "pop %rbp; ret", it won't step into these instructions. Instead it
> will execute past them directly.
> >> I didn't experiment with x86 pc-relative addressing; but I guess it
> will also recognize and execute past this pattern directly.
> >>
> >> So for compiler generated functions, what we do now with assembly
> parser now can be done with CFI + those gdb hacks.
> >> And for hand-written assembly, i think CFI is almost always precise at
> instruction level. In this case, utilizing CFI instead of assembly parser
> will be a big help.
> >>
> >> So maybe we can apply those hacks, and trust CFI only for x86 & x86_64
> targets?
> >>
> >>
> >> On Thu, Jul 31, 2014 at 12:02 AM, Jason Molenda <jmolenda at apple.com>
> wrote:
> >> I think we could think of five levels of eh_frame information:
> >>
> >>
> >> 1 unwind instructions at exception throw locations & locations where a
> callee may throw an exception
> >>
> >> 2 unwind instructions that describe the prologue
> >>
> >> 3 unwind instructions that describe the epilogue at the end of the
> function
> >>
> >> 4 unwind instructions that describe mid-function epilogues (I see these
> on arm all the time, don't see them on x86 with compiler generated code -
> but we don't use eh_frame on arm at Apple, I'm just mentioning it for
> completeness)
> >>
> >> 5 unwind instructions that describe any changes mid-function needed to
> unwind at all instructions ("asynchronous unwind information")
> >>
> >>
> >> The eh_frame section only guarantees #1. gcc and clang always do #1
> and #2. Modern gcc's do #3. I don't know if gcc would do #4 on arm but
> it's not important, I just mention it for completeness. And no one does #5
> (as far as I know), even in the DWARF debug_frame section.
> >>
> >> I think it maybe possible to detect if an eh_frame entry fulfills #3 by
> looking if the CFA definition on the last row is the same as the initial
> CFA definition. But I'm not sure how a debugger could use heuristics to
> determine much else.
> >>
> >>
> >> In fact, detecting #3 may be the easiest thing to detect. I'm not sure
> if the debugger could really detect #2 except maybe if the function had a
> standard prologue (push rbp, mov rsp rbp) and the eh_frame didn't describe
> the effects of these instructions, the debugger could know that the
> eh_frame does not describe the prologue.
> >>
> >>
> >>
> >>
> >>> On Jul 30, 2014, at 6:58 PM, Tong Shen <endlessroad at google.com> wrote:
> >>>
> >>> Ah I understand now.
> >>>
> >>> Now prologue seems always included in CFI fro gcc & clang; and newer
> gcc includes epilogue as well.
> >>> Maybe we can detect and use them when they are available?
> >>>
> >>>
> >>> On Wed, Jul 30, 2014 at 6:44 PM, Jason Molenda <jmolenda at apple.com>
> wrote:
> >>> Ah, it looks like gcc changed since I last looked at its eh_frame
> output.
> >>>
> >>> It's not a bug -- the eh_frame unwind instructions only need to be
> accurate at instructions where an exception can be thrown, or where a
> callee function can throw an exception. There's no requirement to include
> prologue or epilogue instructions in the eh_frame.
> >>>
> >>> And unfortunately from lldb's perspective, when we see eh_frame we'll
> never know how descriptive it is. If it's old-gcc or clang, it won't
> include epilogue instructions. If it's from another compiler, it may not
> include any prologue/epilogue instructions at all.
> >>>
> >>> Maybe we could look over the UnwindPlan rows and see if the CFA
> definition of the last row matches the initial row's CFA definition. That
> would show that the epilogue is described. Unless it is a tail-call (aka
> noreturn) function - in which case the stack is never restored.
> >>>
> >>>
> >>>
> >>>
> >>>> On Jul 30, 2014, at 6:32 PM, Tong Shen <endlessroad at google.com>
> wrote:
> >>>>
> >>>> GCC seems to generate a row for epilogue.
> >>>> Do you think this is a clang bug, or at least a discrepancy between
> clang & gcc?
> >>>>
> >>>> Source:
> >>>> int f() {
> >>>> puts("HI\n");
> >>>> return 5;
> >>>> }
> >>>>
> >>>> Compile option: only -g
> >>>>
> >>>> gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
> >>>> clang version 3.5.0 (213114)
> >>>>
> >>>> Env: Ubuntu 14.04, x86_64
> >>>>
> >>>> drawfdump -F of clang binary:
> >>>> < 2><0x00400530:0x00400559><f><fde offset 0x00000088 length:
> 0x0000001c><eh aug data len 0x0>
> >>>> 0x00400530: <off cfa=08(r7) > <off r16=-8(cfa) >
> >>>> 0x00400531: <off cfa=16(r7) > <off r6=-16(cfa) > <off
> r16=-8(cfa) >
> >>>> 0x00400534: <off cfa=16(r6) > <off r6=-16(cfa) > <off
> r16=-8(cfa) >
> >>>>
> >>>> drawfdump -F of gcc binary:
> >>>> < 1><0x0040052d:0x00400542><f><fde offset 0x00000070 length:
> 0x0000001c><eh aug data len 0x0>
> >>>> 0x0040052d: <off cfa=08(r7) > <off r16=-8(cfa) >
> >>>> 0x0040052e: <off cfa=16(r7) > <off r6=-16(cfa) > <off
> r16=-8(cfa) >
> >>>> 0x00400531: <off cfa=16(r6) > <off r6=-16(cfa) > <off
> r16=-8(cfa) >
> >>>> 0x00400541: <off cfa=08(r7) > <off r6=-16(cfa) > <off
> r16=-8(cfa) >
> >>>>
> >>>>
> >>>> On Wed, Jul 30, 2014 at 5:43 PM, Jason Molenda <jmolenda at apple.com>
> wrote:
> >>>> I'm open to trying to trust eh_frame at frame 0 for x86_64. The lack
> of epilogue descriptions in eh_frame is the biggest problem here.
> >>>>
> >>>> When you "step" or "next" in the debugger, the debugger instruction
> steps across the source line until it gets to the next source line. Every
> time it stops after an instruction step, it confirms that it is (1) between
> the start and end pc values for the source line, and (2) that the "stack
> id" (start address of the function + CFA address) is the same. If it stops
> and the stack id has changed, for a "next" command, it will backtrace one
> stack frame to see if it stepped into a function. If so, it sets a
> breakpoint on the return address and continues.
> >>>>
> >>>> If you switch lldb to prefer eh_frame instructions for x86_64, e.g.
> >>>>
> >>>> Index: source/Plugins/Process/Utility/RegisterContextLLDB.cpp
> >>>> ===================================================================
> >>>> --- source/Plugins/Process/Utility/RegisterContextLLDB.cpp
> (revision 214344)
> >>>> +++ source/Plugins/Process/Utility/RegisterContextLLDB.cpp
> (working copy)
> >>>> @@ -791,6 +791,22 @@
> >>>> }
> >>>> }
> >>>>
> >>>> + // For x86_64 debugging, let's try using the eh_frame
> instructions even if this is the currently
> >>>> + // executing function (frame zero).
> >>>> + Target *target = exe_ctx.GetTargetPtr();
> >>>> + if (target
> >>>> + && (target->GetArchitecture().GetCore() ==
> ArchSpec::eCore_x86_64_x86_64h
> >>>> + || target->GetArchitecture().GetCore() ==
> ArchSpec::eCore_x86_64_x86_64))
> >>>> + {
> >>>> + unwind_plan_sp = func_unwinders_sp->GetUnwindPlanAtCallSite
> (m_current_offset_backed_up_one);
> >>>> + int valid_offset = -1;
> >>>> + if (IsUnwindPlanValidForCurrentPC(unwind_plan_sp,
> valid_offset))
> >>>> + {
> >>>> + UnwindLogMsgVerbose ("frame uses %s for full UnwindPlan,
> preferred over assembly profiling on x86_64",
> unwind_plan_sp->GetSourceName().GetCString());
> >>>> + return unwind_plan_sp;
> >>>> + }
> >>>> + }
> >>>> +
> >>>> // Typically the NonCallSite UnwindPlan is the unwind created by
> inspecting the assembly language instructions
> >>>> if (behaves_like_zeroth_frame)
> >>>> {
> >>>>
> >>>>
> >>>> you'll find that you have to "next" twice to step out of a function.
> Why? With a simple function like:
> >>>>
> >>>> * thread #1: tid = 0xaf31e, 0x0000000100000eb9 a.out`foo + 25 at
> a.c:5, queue = 'com.apple.main-thread', stop reason = step over
> >>>> #0: 0x0000000100000eb9 a.out`foo + 25 at a.c:5
> >>>> 2 int foo ()
> >>>> 3 {
> >>>> 4 puts("HI");
> >>>> -> 5 return 5;
> >>>> 6 }
> >>>> 7
> >>>> 8 int bar ()
> >>>> (lldb) disass
> >>>> a.out`foo at a.c:3:
> >>>> 0x100000ea0: pushq %rbp
> >>>> 0x100000ea1: movq %rsp, %rbp
> >>>> 0x100000ea4: subq $0x10, %rsp
> >>>> 0x100000ea8: leaq 0x6b(%rip), %rdi ; "HI"
> >>>> 0x100000eaf: callq 0x100000efa ; symbol stub for:
> puts
> >>>> 0x100000eb4: movl $0x5, %ecx
> >>>> -> 0x100000eb9: movl %eax, -0x4(%rbp)
> >>>> 0x100000ebc: movl %ecx, %eax
> >>>> 0x100000ebe: addq $0x10, %rsp
> >>>> 0x100000ec2: popq %rbp
> >>>> 0x100000ec3: retq
> >>>>
> >>>>
> >>>> if you do "next" lldb will instruction step, comparing the stack ID
> at every stop, until it gets to 0x100000ec3 at which point the stack ID
> will change. The CFA address (which the eh_frame tells us is rbp+16) just
> changed to the caller's CFA address because we're about to return. The
> eh_frame instructions really need to tell us that the CFA is now rsp+8 at
> 0x100000ec3.
> >>>>
> >>>> The end result is that you need to "next" twice to step out of a
> function.
> >>>>
> >>>> AssemblyParse_x86 has a special bit where it looks or the 'ret'
> instruction sequence at the end of the function -
> >>>>
> >>>> // Now look at the byte at the end of the AddressRange for a
> limited attempt at describing the
> >>>> // epilogue. We're looking for the sequence
> >>>>
> >>>> // [ 0x5d ] mov %rbp, %rsp
> >>>> // [ 0xc3 ] ret
> >>>> // [ 0xe8 xx xx xx xx ] call __stack_chk_fail (this is sometimes
> the final insn in the function)
> >>>>
> >>>> // We want to add a Row describing how to unwind when we're
> stopped on the 'ret' instruction where the
> >>>> // CFA is no longer defined in terms of rbp, but is now defined in
> terms of rsp like on function entry.
> >>>>
> >>>>
> >>>> and adds an extra row of unwind details for that instruction.
> >>>>
> >>>>
> >>>> I mention x86_64 as being a possible good test case here because I
> worry about the i386 picbase sequence (call next-instruction; pop $ebx)
> which occurs a lot. But for x86_64, my main concern is the epilogues.
> >>>>
> >>>>
> >>>>
> >>>>> On Jul 30, 2014, at 2:52 PM, Tong Shen <endlessroad at google.com>
> wrote:
> >>>>>
> >>>>> Thanks Jason! That's a very informative post, clarify things a lot
> :-)
> >>>>>
> >>>>> Well I have to admit that my patch is specifically for certain kind
> of functions, and now I see that's not the general case.
> >>>>>
> >>>>> I did some experiment with gdb. gdb uses CFI for frame 0, either x86
> or x86_64. It looks for FDE of frame 0, and do CFA calculations according
> to that.
> >>>>>
> >>>>> - For compiler generated functions: I think there are 2 usage
> scenarios for frame 0: breakpoint and signal.
> >>>>> - Breakpoints are usually at source line boundary instead of
> instruction boundary, and generally we won't be caught at stack pointer
> changing locations, so CFI is still valid.
> >>>>> - For signal, synchronous unwind table may not be sufficient
> here. But only stack changing instructions will cause incorrect CFA
> calculation, so it' not always the case.
> >>>>> - For hand written assembly functions: from what I've seen, most of
> the time CFI is present and actually asynchronous.
> >>>>> So it seems that in most cases, even with only synchronous unwind
> table, CFI is still correct.
> >>>>>
> >>>>> I believe we can trust eh_frame for frame 0 and use assembly
> profiling as fallback. If both failed, maybe code owner should use
> -fasynchronous-unwind-tables :-)
> >>>>>
> >>>>>
> >>>>> On Tue, Jul 29, 2014 at 4:59 PM, Jason Molenda <jmolenda at apple.com>
> wrote:
> >>>>> It was a tricky one and got lost in the shuffle of a busy week. I
> was always reluctant to try profiling all the instructions in a function.
> On x86, compiler generated code (gcc/clang anyway) is very simplistic about
> setting up the stack frame at the start and only having one epilogue - so
> anything fancier risked making mistakes and could possibly have a
> performance impact as we run functions through the disassembler.
> >>>>>
> >>>>> For hand-written assembly functions (which can be very creative with
> their prologue/epilogue and where it is placed), my position is that they
> should write eh_frame instructions in their assembly source to tell lldb
> where to find things. There is one or two libraries on Mac OS X where we
> break the "ignore eh_frame for the currently executing function" because
> there are many hand-written assembly functions in there and the eh_frame is
> going to beat our own analysis.
> >>>>>
> >>>>>
> >>>>> After I wrote the x86 unwinder, Greg and Caroline implemented the
> arm unwinder where it emulates every instruction in the function looking
> for prologue/epilogue instructions. We haven't seen it having a
> particularly bad impact performance-wise (lldb only does this disassembly
> for functions that it finds on stacks during an execution run, and it saves
> the result so it won't re-compute it for a given function). The clang
> armv7 codegen often has mid-function epilogues (early returns) which
> definitely complicated things and made it necessary to step through the
> entire function bodies. There's a bunch of code I added to support these
> mid-function epilogues - I have to save the register save state when I see
> an instruction which looks like an epilogue, and when I see the final ret
> instruction (aka restoring the saved lr contents into pc), I re-install the
> register save state from before the epilogue started.
> >>>>>
> >>>>> These things always make me a little nervous because the instruction
> analyzer obviously is doing a static analysis so it knows nothing about
> flow control. Tong's patch stops when it sees the first CALL instruction -
> but that's not right, that's just solving the problem for his particular
> function which doesn't have any CALL instructions before his prologue. :)
> You could imagine a function which saves a couple of registers, calls
> another function, then saves a couple more because it needs more scratch
> registers.
> >>>>>
> >>>>> If we're going to change to profiling deep into the function -- and
> I'm not opposed to doing that, it's been fine on arm -- we should just do
> the entire function I think.
> >>>>>
> >>>>>
> >>>>> Another alternative would be to trust eh_frame on x86_64 at frame
> 0. This is one of those things where there's not a great solution. The
> unwind instructions in eh_frame are only guaranteed to be accurate for
> synchronous unwinds -- that is, they are only guaranteed to be accurate at
> places where an exception could be thrown - at call sites. So for
> instances, there's no reason why the compiler has to describe the function
> prologue instructions at all. There's no requirement that the eh_frame
> instructions describe the epilogue instructions. The information about
> spilled registers only needs to be emitted where we could throw an
> exception, or where a callee could throw an exception.
> >>>>>
> >>>>> clang/gcc both emit detailed instructions for the prologue setup.
> But for i386 codegen if the compiler needs to access some pc-relative data,
> it will do a "call next-instruction; pop %eax" to get the current pc
> value. (x86_64 has rip-relative addressing so this isn't needed) If
> you're debugging -fomit-frame-pointer code, that means your CFA is
> expressed in terms of the stack pointer and the stack pointer just changed
> mid-function --- and eh_frame instructions don't describe this.
> >>>>>
> >>>>> The end result: If you want accurate unwinds 100% of the time, you
> can't rely on the unwind instructions from eh_frame. But they'll get you
> accurate unwinds 99.9% of the time ... also, last I checked, neither clang
> nor gcc describe the epilogue instructions.
> >>>>>
> >>>>>
> >>>>> In *theory* the unwind instructions from the DWARF debug_frame
> section should be asynchronous -- they should describe how to find the CFA
> address for every instruction in the function. Which makes sense - you
> want eh_frame to be compact because it's bundled into the executable, so it
> should only have the information necessary for exception handling and you
> can put the verbose stuff in debug_frame DWARF for debuggers. But instead
> (again, last time I checked), the compilers put the exact same thing in
> debug_frame even if you use the -fasynchronous-unwind-tables (or whatever
> that switch was) option.
> >>>>>
> >>>>>
> >>>>> So I don't know, maybe we should just start trusting eh_frame at
> frame 0 and write off those .1% cases where it isn't correct instead of
> trying to get too fancy with the assembly analysis code.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On Jul 29, 2014, at 4:17 PM, Todd Fiala <tfiala at google.com> wrote:
> >>>>>>
> >>>>>> Hey Jason,
> >>>>>>
> >>>>>> Do you have any feedback on this?
> >>>>>>
> >>>>>> Thanks!
> >>>>>>
> >>>>>> -Todd
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Jul 25, 2014 at 1:42 PM, Tong Shen <endlessroad at google.com>
> wrote:
> >>>>>> Sorry, wrong version of patch...
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Jul 25, 2014 at 1:41 PM, Tong Shen <endlessroad at google.com>
> wrote:
> >>>>>> Hi Molenda, lldb-commits,
> >>>>>>
> >>>>>> For now, x86 assembly profiler will stop after 10 "non-prologue"
> instructions. In practice it may not be sufficient. For example, we have a
> hand-written assembly function, which have hundreds of instruction before
> actual (stack-adjusting) prologue instructions.
> >>>>>>
> >>>>>> One way is to change the limit to 1000; but there will always be
> functions that break the limit :-) I believe the right thing to do here is
> parsing all instructions before "ret"/"call" as prologue instructions.
> >>>>>>
> >>>>>> Here's what I changed:
> >>>>>> - For "push %rbx" and "mov %rbx, -8(%rbp)": only add first row for
> that register. They may appear multiple times in function body. But as long
> as one of them appears, first appearance should be in prologue(If it's not
> in prologue, this function will not use %rbx, so these 2 instructions
> should not appear at all).
> >>>>>> - Also monitor "add %rsp 0x20".
> >>>>>> - Remove non prologue instruction count.
> >>>>>> - Add "call" instruction detection, and stop parsing after it.
> >>>>>>
> >>>>>> Thanks.
> >>>>>>
> >>>>>> --
> >>>>>> Best Regards, Tong Shen
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Best Regards, Tong Shen
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> lldb-commits mailing list
> >>>>>> lldb-commits at cs.uiuc.edu
> >>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Todd Fiala | Software Engineer | tfiala at google.com |
> 650-943-3180
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Best Regards, Tong Shen
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Best Regards, Tong Shen
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Best Regards, Tong Shen
> >>
> >>
> >>
> >>
> >> --
> >> Best Regards, Tong Shen
> >>
> >>
> >>
> >> --
> >> Best Regards, Tong Shen
> >> <adjust_cfi_for_frame_zero.patch>
> >
>
>
--
Best Regards, Tong Shen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20140819/ade1abf9/attachment.html>
More information about the lldb-commits
mailing list