wrong line number in breakpoint location
authorJoel Brobecker <brobecker@adacore.com>
Mon, 22 Jan 2018 04:14:50 +0000 (23:14 -0500)
committerJoel Brobecker <brobecker@adacore.com>
Mon, 22 Jan 2018 04:14:50 +0000 (23:14 -0500)
commita9e408182d2faaed5c2457b68ea3276c719a590f
tree3c85bf88a11565635690213d2b67a389c5f9adc6
parent3b76a4a069d43c5a641914707554a6e90dbd2fd9
wrong line number in breakpoint location

Consider the following situation, where we have one file containing...

    $ cat -n body.inc
         1  i = i + 1;

... we include that file from some code, like so:

    $ cat -n cat -n small.c
        [...]
        17  int
        18  next (int i)
        19  {
        20  #include "body.inc"
        21    return i;
        22  }

When trying to insert a breakpoint on line 18, for instance:

    (gdb) b small.c:18
    Breakpoint 1 at 0x40049f: file body.inc, line 18.
                                                  ^^
                                                  ||

Here, the issue is that GDB reports the breakpoint to be in file
body.inc, which is true, but with the line number that corresponding
to the user-requested location, which is not correct.

Although the simple reproducer may look slightly artificial,
the above is simply one way to reproduce the same issue observed
when trying to insert a breakpoint on a function provided in
a .h files and then subsequently inlined in a C file.

What happens is the following:

  1. We resolve the small.c:18 linespec into a symtab_and_line which
     has "small.c" and 18 as the symtab and line number.

  2. Next, we call skip_prologue_sal, which calculates the PC
     past the prologue, and updates the symtab_and_line: PC,
     but also symtab (now body.inc) and the new line (now 1).

  3. However, right after that, we do:

            /* Make sure the line matches the request, not what was
               found.  */
            intermediate_results.sals[i].line = val.line;

We should either restore both symtab and line, or leave the actual
line to match the actual symtab.  This patch chose the latter.
This introduces a few changes in a few tests, which required some
updates, but looking at those change, I believe them to be expected.

gdb/ChangeLog:

        * linespec.c (create_sals_line_offset): Remove code that preserved
        the symtab_and_line's line number.

gdb/testsuite/ChangeLog:

        * gdb.base/break-include.c, gdb.base/break-include.inc,
        gdb.base/break-include.exp: New files.
        * gdb.base/ending-run.exp: Minor adaptations due to the breakpoint's
        line number now being the actual line number where the breakpoint
        was inserted.
        * gdb.mi/mi-break.exp: Likewise.
        * gdb.mi/mi-reverse.exp: Likewise.
        * gdb.mi/mi-simplerun.exp: Ditto.

Tested on x86_64-linux.
gdb/ChangeLog
gdb/linespec.c
gdb/testsuite/ChangeLog
gdb/testsuite/gdb.base/break-include.c [new file with mode: 0644]
gdb/testsuite/gdb.base/break-include.exp [new file with mode: 0644]
gdb/testsuite/gdb.base/break-include.inc [new file with mode: 0644]
gdb/testsuite/gdb.base/ending-run.exp
gdb/testsuite/gdb.mi/mi-break.exp
gdb/testsuite/gdb.mi/mi-reverse.exp
gdb/testsuite/gdb.mi/mi-simplerun.exp