[cfe-dev] debug line info of a landing pad

[Gao, Yunzhong]

Hi,

As a basis of this discussion, I compile the following two C++ files and
then step through them with gdb 7.2.

$ clang++ -g test1.cc test2.cc -o a.out
$ gdb a.out

/* begin of test1.cc */
struct foo {
  foo();
  ~foo();
  int get() { return a; }

private:
  int a;
};

foo::foo() { a = 16; }
foo::~foo() { a = 0; }

extern "C" void call_me_yellow();
extern "C" void call_you_green();

int main()
{
  int c = 100;

  try {
    foo my_foo;
    call_me_yellow(); // landing pad #1

    foo your_foo;
    call_you_green(); // landing pad #2
  }

  catch (int a) {
    c = a;
  }

  return c;
}
/* end of test1.cc */


/* begin of test2.cc */
extern "C" void call_me_yellow()
{
  throw 1;
}

extern "C" void call_you_green()
{
  throw 2;
}
/* end of test2.cc */

Since call_me_yellow() could throw an exception, Clang generates a landing
pad for it. The debug line info of this landing pad is associated with the
function call. If I set a breakpoint on the landing pad in gdb, this source
line shows up when the breakpoint is hit.
22          call_me_yellow(); // landing pad #1

One customer asked, why does the debugger not stop at the beginning of the
catch block when the exception is thrown.

If I compile using GCC 4.4.3, the landing pads do not have associated debug
line info, and because they immediately follow the generated codes for the
try block, they implicitly get attached to the last statement in the try
block. If I set a breakpoint on the landing pad in gdb, this source line
shows up when the breakpoint is hit. Not really at the beginning of the catch
block, but closer.
25          call_you_green(); // landing pad #2

So my question is, should the landing pads have associated debug line info at
all, and what do you think are the reasonable source lines to attach them to?
Here are some of the options that I can think of:
    (a)  no debug line info (like what gcc does)
    (b)  the call site      (like what clang does)
    (c)  the beginning of the (lexicographically) first catch block if any;
    (d)  the end of the innermost enclosing try block;

The same questions could be asked regarding the EHResume block as well.

As a side note, in gdb, I had to use "break *<address>" to put a breakpoint
on the landing pad; "break test1.cc:22" does not put a breakpoint on the
landing pad. This seems like a gdb bug, although, for this discussion, I'd
like to focus on the debug info generated by the compiler.

Thanks for your options,
- Gao.