Re: [RFA/linespec] wrong line number in breakpoint location

[Simon Marchi <simon.marchi@ericsson.com>]

On 2017-12-21 06:32 AM, Joel Brobecker wrote:
> [with the patch, this time...]
> 
> On Thu, Dec 21, 2017 at 03:31:27PM +0400, Joel Brobecker wrote:
>>>> /* The following function's implementation starts by including a file
>>>>    (break-include.inc) which contains a copyright header followed by
>>>>    a single C statement.  When we break on the line where the function
>>>
>>> I would say "place a breakpoint" instead of break.  For me "to break" is the
>>> action of the program stopping on a breakpoint (though maybe it
>>
>> Sounds good.
>>
>> Here is a new version :). I also noticed I forgot the gdb.base/
>> subdir in the name of the new files in the testsuite, so I fixed
>> that up too.
>>
>> 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.
>>
>> Thanks,
>> -- 
>> Joel
> 

Hi Joel,

I started seeing a failure with this patch:

FAIL: gdb.base/break.exp: verify that they were cleared

Here is the test code:

 40 int
 41 main (int argc, char **argv, char **envp)
 42 {
 43     if (argc == 12345) {  /* an unlikely value < 2^16, in case uninited */ /* set breakpoint 6 here */
 44         fprintf (stderr, "usage:  factorial <number>\n");
 45         return 1;
 46     }
 47     printf ("%d\n", factorial (atoi ("6")));  /* set breakpoint 1 here */
 48     /* set breakpoint 12 here */
 49     marker1 ();  /* set breakpoint 11 here */
 50     marker2 (43); /* set breakpoint 20 here */

What happens is that we build a binary with optimization, set a breakpoint
on line 47, and expect "info break" to show it at line 47.  In reality,
everything about line 47 has been inlined and there's no address associated to
line 47.  The following location in that file that has generated code associated
to it is line 49, so that's where the breakpoint is placed in reality.  With
this patch, "info break" therefore now shows line 49.

This particular test isn't really about testing with optimized code, it's about
checking if we can clear breakpoint commands.  So we should probably test that
against a non-optimized binary.

I am using Ubuntu 16.04's default compiler, gcc 5.4.0 (the outcome of the test probably
depends on the particular compiler used).  When I try on my Arch Linux machine and
gcc 7.2.1, the test passes (the generated address/line mapping is different, and
there's an address associated to line 47).

Simon