<div dir="ltr">I don't necessarily have any brilliant ideas here. I think, in general, that I'd expect them to have a line number of the closing brace as a "doing something not listed in the actual code" and in particular a column number of the closing brace in cases where we care about that.<div>
<br></div><div>-eric</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 7, 2013 at 10:45 AM, Robinson, Paul <span dir="ltr"><<a href="mailto:Paul.Robinson@am.sony.com" target="_blank">Paul.Robinson@am.sony.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+Eric, ping?<br>
<div class="im HOEnZb"><br>
> -----Original Message-----<br>
> From: <a href="mailto:cfe-dev-bounces@cs.uiuc.edu">cfe-dev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:cfe-dev-bounces@cs.uiuc.edu">cfe-dev-bounces@cs.uiuc.edu</a>]<br>
</div><div class="HOEnZb"><div class="h5">> On Behalf Of Robinson, Paul<br>
> Sent: Tuesday, February 05, 2013 12:17 PM<br>
> To: Gao, Yunzhong; <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> Subject: Re: [cfe-dev] debug line info of a landing pad<br>
><br>
> > From: <a href="mailto:cfe-dev-bounces@cs.uiuc.edu">cfe-dev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:cfe-dev-bounces@cs.uiuc.edu">cfe-dev-bounces@cs.uiuc.edu</a>]<br>
> > On Behalf Of Gao, Yunzhong<br>
> ><br>
> > As a basis of this discussion, I compile the following two C++ files<br>
> and<br>
> > then step through them with gdb 7.2.<br>
> ><br>
> > $ clang++ -g test1.cc test2.cc -o a.out<br>
> > $ gdb a.out<br>
> ><br>
> > /* begin of test1.cc */<br>
> > struct foo {<br>
> >   foo();<br>
> >   ~foo();<br>
> >   int get() { return a; }<br>
> ><br>
> > private:<br>
> >   int a;<br>
> > };<br>
> ><br>
> > foo::foo() { a = 16; }<br>
> > foo::~foo() { a = 0; }<br>
> ><br>
> > extern "C" void call_me_yellow();<br>
> > extern "C" void call_you_green();<br>
> ><br>
> > int main()<br>
> > {<br>
> >   int c = 100;<br>
> ><br>
> >   try {<br>
> >     foo my_foo;<br>
> >     call_me_yellow(); // landing pad #1<br>
> ><br>
> >     foo your_foo;<br>
> >     call_you_green(); // landing pad #2<br>
> >   }<br>
> ><br>
> >   catch (int a) {<br>
> >     c = a;<br>
> >   }<br>
> ><br>
> >   return c;<br>
> > }<br>
> > /* end of test1.cc */<br>
> ><br>
> ><br>
> > /* begin of test2.cc */<br>
> > extern "C" void call_me_yellow()<br>
> > {<br>
> >   throw 1;<br>
> > }<br>
> ><br>
> > extern "C" void call_you_green()<br>
> > {<br>
> >   throw 2;<br>
> > }<br>
> > /* end of test2.cc */<br>
> ><br>
> > Since call_me_yellow() could throw an exception, Clang generates a<br>
> > landing<br>
> > pad for it. The debug line info of this landing pad is associated with<br>
> > the<br>
> > function call. If I set a breakpoint on the landing pad in gdb, this<br>
> > source<br>
> > line shows up when the breakpoint is hit.<br>
> > 22          call_me_yellow(); // landing pad #1<br>
> ><br>
> > One customer asked, why does the debugger not stop at the beginning of<br>
> > the<br>
> > catch block when the exception is thrown.<br>
> ><br>
> > If I compile using GCC 4.4.3, the landing pads do not have associated<br>
> > debug<br>
> > line info, and because they immediately follow the generated codes for<br>
> > the<br>
> > try block, they implicitly get attached to the last statement in the<br>
> try<br>
> > block. If I set a breakpoint on the landing pad in gdb, this source<br>
> line<br>
> > shows up when the breakpoint is hit. Not really at the beginning of<br>
> the<br>
> > catch<br>
> > block, but closer.<br>
> > 25          call_you_green(); // landing pad #2<br>
> ><br>
> > So my question is, should the landing pads have associated debug line<br>
> > info at<br>
> > all, and what do you think are the reasonable source lines to attach<br>
> > them to?<br>
> > Here are some of the options that I can think of:<br>
> >     (a)  no debug line info (like what gcc does)<br>
> >     (b)  the call site      (like what clang does)<br>
> >     (c)  the beginning of the (lexicographically) first catch block if<br>
> > any;<br>
> >     (d)  the end of the innermost enclosing try block;<br>
> ><br>
> > The same questions could be asked regarding the EHResume block as<br>
> well.<br>
><br>
> I discussed this with Gao but we'd like some feedback from outside.<br>
> Basically, (a) means that the landing pad block becomes associated with<br>
> the same source loc as the block that physically precedes it, which is<br>
> not entirely predictable. I can understand why (b) happens but I think<br>
> really (c) or maybe (d) would be preferable from a debugging-experience<br>
> perspective.<br>
><br>
> Also I think the more likely scenario is not so much trying to set a<br>
> breakpoint on the landing pad (which requires real effort on the part<br>
> of the user) but 'step' or 'finish' over a throw.<br>
><br>
> Eric/David, any thoughts here?<br>
> Thanks,<br>
> --paulr<br>
><br>
> ><br>
> > As a side note, in gdb, I had to use "break *<address>" to put a<br>
> > breakpoint<br>
> > on the landing pad; "break test1.cc:22" does not put a breakpoint on<br>
> the<br>
> > landing pad. This seems like a gdb bug, although, for this discussion,<br>
> > I'd<br>
> > like to focus on the debug info generated by the compiler.<br>
> ><br>
> > Thanks for your options,<br>
> > - Gao.<br>
><br>
><br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br>
</div></div></blockquote></div><br></div>