On Apr 23, 2013, at 4:00 PM, Eric Christopher <[email protected]> wrote:
> Not sure what you mean, I'm curious why the arc code is getting line
> information associated with the end of the block even at the
> beginning? Same with blocks. (To be fair I didn't implement that front
> end part so I'm relying on you to know since you're adjusting it :)
With blocks the problem is that we insert an extra alloca and some setup code
into the prologue, but unless we set the DebugLoc to an empty location that
code will have line info attached to it. This in turn will trigger the
heuristic in AsmPrinter/DwarfDebug to believe that it should emit the
prologue_end flag when in fact we are still in the middle of the frame setup.
Which will cause some debugger tests to fail. I think that that is fairly
uncontroversial.
Lets move over to the interesting part:
With ARC the problem is closer to the C++ example you provided the other day.
After reconsidering the problem you got me convinced (thanks!) that removing
the debug info for the ARC cleanup code goes a bit too far. The problem is that
if we have only a single return statement in the function -- especially one
where the return expression does not use anything that needs to be cleaned up
-- the (ARC) cleanup code will be the first non-prologue (linetable-)stmt in
the function. That means we *need* to provide a breakpoint there, otherwise the
user can’t inspect the values before they get cleaned up.
1 - (int)testFoo:(NSString *)foo {
2 return 1;
3 } // Cleanup code, comes before ret 1, but has a higher line number
My new patch ensures that the line table is always sequential. If there is
cleanup code and a single return statement it essentially flips their debug
locations so the first breakpoint in the function is before the cleanup code
and in a location that does not confuse the user.
In any function, if there is cleanup code, it will get the debug location of
the ‘}’ *and* the ret instruction in the epilog will have no debug location, so
the debugger doesn’t jump back into the function body again. There is nothing
to see there anyway :-)
I tried it on your C++ example and it seemed reasonable, too.
It also should be very close to the behavior of GCC that David mentioned the
other day where the return expression is at the line of the return statement
and the cleanup code and actual return are t the closing brace of the scope.
thanks!
Adrian
0002-Ensure-that-the-line-table-for-functions-with-cleanu.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
