<div dir="ltr">Ahh sorry I've been working on something else this week and didn't get back to you in time.<div>And you've been very patient and informative. Thanks!<br><div><br></div><div>I'm only suggesting it for x86 / x86_64. What I am doing here relies on:</div>
<div>- Compiler describes prologue;</div><div>- We can figure our all mid function CFA changes by inspecting instructions.</div><div><br></div><div>For frame 0, the new progress for CFA locating will look like this:</div>
<div>- Find the nearest CFI available before current PC.</div><div>- If the CFI is for current PC, viola :-) If not, continue.</div><div>- Inspect all instructions in between, and make changes to CFA accordingly. This can solve the PC relative addressing case.</div>
<div>- 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.</div><div><br></div><div>From what I've seen so far, this actually can solve most of gcc/clang generated code.</div>
<div>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).\</div><div><br></div><div>I hope I explain my thoughts clearly.</div>
<div><br></div><div>Thank you.</div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 19, 2014 at 4:22 PM, Jason Molenda <span dir="ltr"><<a href="mailto:jmolenda@apple.com" target="_blank">jmolenda@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Tong, my message was a little rambling. Let's be specific.<br>
<br>
We are changing lldb to trust eh_frame instructions on the currently-executing aka 0th frame.<br>
<br>
In practice, gcc and clang eh_frame both describe the prologue, so this is OK.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
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.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
> On Aug 15, 2014, at 8:07 PM, Jason Molenda <<a href="mailto:jmolenda@apple.com">jmolenda@apple.com</a>> wrote:<br>
><br>
> Hi Tong, sorry for the delay in replying.<br>
><br>
> 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.<br>
><br>
> 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<br>
><br>
> #include <stdio.h><br>
> int main()<br>
> {<br>
> puts ("HI");<br>
> }<br>
><br>
> Most codegen will use a sequence like<br>
><br>
> call LNextInstruction<br>
> .LNextInstruction<br>
> pop ebx<br>
><br>
> 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?<br>
><br>
> 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.<br>
><br>
><br>
> 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.<br>
><br>
><br>
> You'd want to update the UnwindLogMsgVerbose() text, of course.<br>
><br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
><br>
> 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.<br>
><br>
> J<br>
><br>
><br>
>> On Aug 14, 2014, at 6:31 PM, Tong Shen <<a href="mailto:endlessroad@google.com">endlessroad@google.com</a>> wrote:<br>
>><br>
>> Hi Jason,<br>
>><br>
>> Turns out we still need CFI for frame 0 in certain situations...<br>
>><br>
>> 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.<br>
>><br>
>> Patch attached, now it just implements adjustment for "pop ebp; ret".<br>
>><br>
>> If you think this approach is OK, I will go ahead and add other tricks(i386 pc relative addressing, more styles of epilogue, etc).<br>
>><br>
>> Thank you for your time!<br>
>><br>
>><br>
>> On Thu, Jul 31, 2014 at 12:50 PM, Tong Shen <<a href="mailto:endlessroad@google.com">endlessroad@google.com</a>> wrote:<br>
>> I think gdb's rationale for using CFI for leaf function is:<br>
>> - gcc always generate CFI for progolue, so at function entry, we know the correct CFA;<br>
>> - any stack pointer altering operation after that(mid-function & epilogue), we can recognize and handle them.<br>
>> So basically, it assumes 2, hacks its way through 3 & 4, and pretends we are at 5.<br>
>> Number of hacks we need seems to be small in x86 world, so this tradition is still here.<br>
>><br>
>> 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.<br>
>> I didn't experiment with x86 pc-relative addressing; but I guess it will also recognize and execute past this pattern directly.<br>
>><br>
>> So for compiler generated functions, what we do now with assembly parser now can be done with CFI + those gdb hacks.<br>
>> 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.<br>
>><br>
>> So maybe we can apply those hacks, and trust CFI only for x86 & x86_64 targets?<br>
>><br>
>><br>
>> On Thu, Jul 31, 2014 at 12:02 AM, Jason Molenda <<a href="mailto:jmolenda@apple.com">jmolenda@apple.com</a>> wrote:<br>
>> I think we could think of five levels of eh_frame information:<br>
>><br>
>><br>
>> 1 unwind instructions at exception throw locations & locations where a callee may throw an exception<br>
>><br>
>> 2 unwind instructions that describe the prologue<br>
>><br>
>> 3 unwind instructions that describe the epilogue at the end of the function<br>
>><br>
>> 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)<br>
>><br>
>> 5 unwind instructions that describe any changes mid-function needed to unwind at all instructions ("asynchronous unwind information")<br>
>><br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>><br>
>> 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.<br>
>><br>
>><br>
>><br>
>><br>
>>> On Jul 30, 2014, at 6:58 PM, Tong Shen <<a href="mailto:endlessroad@google.com">endlessroad@google.com</a>> wrote:<br>
>>><br>
>>> Ah I understand now.<br>
>>><br>
>>> Now prologue seems always included in CFI fro gcc & clang; and newer gcc includes epilogue as well.<br>
>>> Maybe we can detect and use them when they are available?<br>
>>><br>
>>><br>
>>> On Wed, Jul 30, 2014 at 6:44 PM, Jason Molenda <<a href="mailto:jmolenda@apple.com">jmolenda@apple.com</a>> wrote:<br>
>>> Ah, it looks like gcc changed since I last looked at its eh_frame output.<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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.<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>>> On Jul 30, 2014, at 6:32 PM, Tong Shen <<a href="mailto:endlessroad@google.com">endlessroad@google.com</a>> wrote:<br>
>>>><br>
>>>> GCC seems to generate a row for epilogue.<br>
>>>> Do you think this is a clang bug, or at least a discrepancy between clang & gcc?<br>
>>>><br>
>>>> Source:<br>
>>>> int f() {<br>
>>>> puts("HI\n");<br>
>>>> return 5;<br>
>>>> }<br>
>>>><br>
>>>> Compile option: only -g<br>
>>>><br>
>>>> gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)<br>
>>>> clang version 3.5.0 (213114)<br>
>>>><br>
>>>> Env: Ubuntu 14.04, x86_64<br>
>>>><br>
>>>> drawfdump -F of clang binary:<br>
>>>> < 2><0x00400530:0x00400559><f><fde offset 0x00000088 length: 0x0000001c><eh aug data len 0x0><br>
>>>> 0x00400530: <off cfa=08(r7) > <off r16=-8(cfa) ><br>
>>>> 0x00400531: <off cfa=16(r7) > <off r6=-16(cfa) > <off r16=-8(cfa) ><br>
>>>> 0x00400534: <off cfa=16(r6) > <off r6=-16(cfa) > <off r16=-8(cfa) ><br>
>>>><br>
>>>> drawfdump -F of gcc binary:<br>
>>>> < 1><0x0040052d:0x00400542><f><fde offset 0x00000070 length: 0x0000001c><eh aug data len 0x0><br>
>>>> 0x0040052d: <off cfa=08(r7) > <off r16=-8(cfa) ><br>
>>>> 0x0040052e: <off cfa=16(r7) > <off r6=-16(cfa) > <off r16=-8(cfa) ><br>
>>>> 0x00400531: <off cfa=16(r6) > <off r6=-16(cfa) > <off r16=-8(cfa) ><br>
>>>> 0x00400541: <off cfa=08(r7) > <off r6=-16(cfa) > <off r16=-8(cfa) ><br>
>>>><br>
>>>><br>
>>>> On Wed, Jul 30, 2014 at 5:43 PM, Jason Molenda <<a href="mailto:jmolenda@apple.com">jmolenda@apple.com</a>> wrote:<br>
>>>> 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.<br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>> If you switch lldb to prefer eh_frame instructions for x86_64, e.g.<br>
>>>><br>
>>>> Index: source/Plugins/Process/Utility/RegisterContextLLDB.cpp<br>
>>>> ===================================================================<br>
>>>> --- source/Plugins/Process/Utility/RegisterContextLLDB.cpp (revision 214344)<br>
>>>> +++ source/Plugins/Process/Utility/RegisterContextLLDB.cpp (working copy)<br>
>>>> @@ -791,6 +791,22 @@<br>
>>>> }<br>
>>>> }<br>
>>>><br>
>>>> + // For x86_64 debugging, let's try using the eh_frame instructions even if this is the currently<br>
>>>> + // executing function (frame zero).<br>
>>>> + Target *target = exe_ctx.GetTargetPtr();<br>
>>>> + if (target<br>
>>>> + && (target->GetArchitecture().GetCore() == ArchSpec::eCore_x86_64_x86_64h<br>
>>>> + || target->GetArchitecture().GetCore() == ArchSpec::eCore_x86_64_x86_64))<br>
>>>> + {<br>
>>>> + unwind_plan_sp = func_unwinders_sp->GetUnwindPlanAtCallSite (m_current_offset_backed_up_one);<br>
>>>> + int valid_offset = -1;<br>
>>>> + if (IsUnwindPlanValidForCurrentPC(unwind_plan_sp, valid_offset))<br>
>>>> + {<br>
>>>> + UnwindLogMsgVerbose ("frame uses %s for full UnwindPlan, preferred over assembly profiling on x86_64", unwind_plan_sp->GetSourceName().GetCString());<br>
>>>> + return unwind_plan_sp;<br>
>>>> + }<br>
>>>> + }<br>
>>>> +<br>
>>>> // Typically the NonCallSite UnwindPlan is the unwind created by inspecting the assembly language instructions<br>
>>>> if (behaves_like_zeroth_frame)<br>
>>>> {<br>
>>>><br>
>>>><br>
>>>> you'll find that you have to "next" twice to step out of a function. Why? With a simple function like:<br>
>>>><br>
>>>> * thread #1: tid = 0xaf31e, 0x0000000100000eb9 a.out`foo + 25 at a.c:5, queue = 'com.apple.main-thread', stop reason = step over<br>
>>>> #0: 0x0000000100000eb9 a.out`foo + 25 at a.c:5<br>
>>>> 2 int foo ()<br>
>>>> 3 {<br>
>>>> 4 puts("HI");<br>
>>>> -> 5 return 5;<br>
>>>> 6 }<br>
>>>> 7<br>
>>>> 8 int bar ()<br>
>>>> (lldb) disass<br>
>>>> a.out`foo at a.c:3:<br>
>>>> 0x100000ea0: pushq %rbp<br>
>>>> 0x100000ea1: movq %rsp, %rbp<br>
>>>> 0x100000ea4: subq $0x10, %rsp<br>
>>>> 0x100000ea8: leaq 0x6b(%rip), %rdi ; "HI"<br>
>>>> 0x100000eaf: callq 0x100000efa ; symbol stub for: puts<br>
>>>> 0x100000eb4: movl $0x5, %ecx<br>
>>>> -> 0x100000eb9: movl %eax, -0x4(%rbp)<br>
>>>> 0x100000ebc: movl %ecx, %eax<br>
>>>> 0x100000ebe: addq $0x10, %rsp<br>
>>>> 0x100000ec2: popq %rbp<br>
>>>> 0x100000ec3: retq<br>
>>>><br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>> The end result is that you need to "next" twice to step out of a function.<br>
>>>><br>
>>>> AssemblyParse_x86 has a special bit where it looks or the 'ret' instruction sequence at the end of the function -<br>
>>>><br>
>>>> // Now look at the byte at the end of the AddressRange for a limited attempt at describing the<br>
>>>> // epilogue. We're looking for the sequence<br>
>>>><br>
>>>> // [ 0x5d ] mov %rbp, %rsp<br>
>>>> // [ 0xc3 ] ret<br>
>>>> // [ 0xe8 xx xx xx xx ] call __stack_chk_fail (this is sometimes the final insn in the function)<br>
>>>><br>
>>>> // We want to add a Row describing how to unwind when we're stopped on the 'ret' instruction where the<br>
>>>> // CFA is no longer defined in terms of rbp, but is now defined in terms of rsp like on function entry.<br>
>>>><br>
>>>><br>
>>>> and adds an extra row of unwind details for that instruction.<br>
>>>><br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>><br>
>>>><br>
>>>>> On Jul 30, 2014, at 2:52 PM, Tong Shen <<a href="mailto:endlessroad@google.com">endlessroad@google.com</a>> wrote:<br>
>>>>><br>
>>>>> Thanks Jason! That's a very informative post, clarify things a lot :-)<br>
>>>>><br>
>>>>> 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.<br>
>>>>><br>
>>>>> 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.<br>
>>>>><br>
>>>>> - For compiler generated functions: I think there are 2 usage scenarios for frame 0: breakpoint and signal.<br>
>>>>> - 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.<br>
>>>>> - 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.<br>
>>>>> - For hand written assembly functions: from what I've seen, most of the time CFI is present and actually asynchronous.<br>
>>>>> So it seems that in most cases, even with only synchronous unwind table, CFI is still correct.<br>
>>>>><br>
>>>>> 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 :-)<br>
>>>>><br>
>>>>><br>
>>>>> On Tue, Jul 29, 2014 at 4:59 PM, Jason Molenda <<a href="mailto:jmolenda@apple.com">jmolenda@apple.com</a>> wrote:<br>
>>>>> 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.<br>
>>>>><br>
>>>>> 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.<br>
>>>>><br>
>>>>><br>
>>>>> 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.<br>
>>>>><br>
>>>>> 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.<br>
>>>>><br>
>>>>> 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.<br>
>>>>><br>
>>>>><br>
>>>>> 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.<br>
>>>>><br>
>>>>> 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.<br>
>>>>><br>
>>>>> 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.<br>
>>>>><br>
>>>>><br>
>>>>> 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.<br>
>>>>><br>
>>>>><br>
>>>>> 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.<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>>> On Jul 29, 2014, at 4:17 PM, Todd Fiala <<a href="mailto:tfiala@google.com">tfiala@google.com</a>> wrote:<br>
>>>>>><br>
>>>>>> Hey Jason,<br>
>>>>>><br>
>>>>>> Do you have any feedback on this?<br>
>>>>>><br>
>>>>>> Thanks!<br>
>>>>>><br>
>>>>>> -Todd<br>
>>>>>><br>
>>>>>><br>
>>>>>> On Fri, Jul 25, 2014 at 1:42 PM, Tong Shen <<a href="mailto:endlessroad@google.com">endlessroad@google.com</a>> wrote:<br>
>>>>>> Sorry, wrong version of patch...<br>
>>>>>><br>
>>>>>><br>
>>>>>> On Fri, Jul 25, 2014 at 1:41 PM, Tong Shen <<a href="mailto:endlessroad@google.com">endlessroad@google.com</a>> wrote:<br>
>>>>>> Hi Molenda, lldb-commits,<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>>> Here's what I changed:<br>
>>>>>> - 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).<br>
>>>>>> - Also monitor "add %rsp 0x20".<br>
>>>>>> - Remove non prologue instruction count.<br>
>>>>>> - Add "call" instruction detection, and stop parsing after it.<br>
>>>>>><br>
>>>>>> Thanks.<br>
>>>>>><br>
>>>>>> --<br>
>>>>>> Best Regards, Tong Shen<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> --<br>
>>>>>> Best Regards, Tong Shen<br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> lldb-commits mailing list<br>
>>>>>> <a href="mailto:lldb-commits@cs.uiuc.edu">lldb-commits@cs.uiuc.edu</a><br>
>>>>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits</a><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> --<br>
>>>>>> Todd Fiala | Software Engineer | <a href="mailto:tfiala@google.com">tfiala@google.com</a> | <a href="tel:650-943-3180" value="+16509433180">650-943-3180</a><br>
>>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> Best Regards, Tong Shen<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> Best Regards, Tong Shen<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Best Regards, Tong Shen<br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Best Regards, Tong Shen<br>
>><br>
>><br>
>><br>
>> --<br>
>> Best Regards, Tong Shen<br>
>> <adjust_cfi_for_frame_zero.patch><br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Best Regards, Tong Shen</div>
</div>