So, since you didn't respond to the rest, these are the similar bugs I was speaking about:
http://llvm.org/bugs/show_bug.cgi?id=14498 http://llvm.org/bugs/show_bug.cgi?id=14580 with a little bit due to: http://llvm.org/bugs/show_bug.cgi?id=14610 http://llvm.org/bugs/show_bug.cgi?id=14473 Before we go forward with this I'd like to discuss the general applicability here for line information. Few notes on the patch: DI->EmitLocation(Builder, - cast<CompoundStmt>(blockDecl->getBody())->getRBracLoc()); + cast<CompoundStmt>(blockDecl->getBody())->getRBracLoc()); Separate cleanup if possible. Thanks. +// This is to ensure that we don't generate bogus debug locations for code inserted by ARC. +// CHECK-NOT: bitcast {{.*}}, !dbg I'm all for short and simple tests, but this might be a bit obscure :) +- (int)testFoo:(NSString *)foo { + // When you stop at this breakpoint, try to `po foo`. It will be nil. + return 1; + + // When you stop at *this* breakpoint, `po foo` works. Note that this one gets + // hit before the other one. This isn't what most developers expect. +} The comments are obviously from the testcase you got, can you instead annotate it with something that's a bit more applicable to the debug code gen sort of things? + /// \brief Temporarily suppress DebugLocations from being attached + /// to emitted instructions, until the next call to + /// SetCurrentDebugLocation() or EnableDebugLocations(). Use this + /// if you want an instruction to be counted towards the prologue or + /// if there is no useful source location. Hrm why not assert that it hasn't been updated in the meantime? -eric On Mon, Apr 8, 2013 at 11:58 AM, Adrian Prantl <[email protected]> wrote: > > On Apr 8, 2013, at 11:06 AM, Eric Christopher <[email protected]> wrote: > >> On Mon, Apr 8, 2013 at 10:40 AM, John McCall <[email protected]> wrote: >>> On Apr 5, 2013, at 5:22 PM, Adrian Prantl <[email protected]> wrote: >>>> Patch for review, mostly for the IRBuilder::DisableDebugLocations() part. >>>> >>>> Do not attach a debug location to code inserted by ARC -- >>>> it would create a spurious line table entry at the closing } of the scope. >>> >>> Is this a problem? Just that we don't want "next" to stop here? >>> >> >> Pretty much. It's analogous to the same when we're looking at >> cleanups, etc. I think this is going into the realm of "opinions on >> behavior" here. There are a couple of bugs off of PR14330 that are >> similar here where the gdb testsuite is checking to see where "next" >> takes you. It's more interesting when you're looking at where next >> takes you in something like: >> >> foo (bar(), baz()) >> >> and you want to make sure that when you "next" out of baz that it >> leaves you on the same line as foo. >> >> For the patch, while I'm not sure we want it, I'd like to see how the >> functionality plays out with other similar constructs in addition to >> just arc to see? > > In the CFE patch I submitted, I'm also using it to make debugging-related > block setup code part of the prologue. But right now I only got the ARC and > the Blocks example. > > -- adrian _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
