Bug ID: 26334
Summary: Line info not retained for some non-empty, is_stmt=1
Assignee: unassigned at sourceware dot org
Reporter: acollier at undo dot io
Target Milestone: ---
gdb seems to be dropping information about some non-empty lines when it builds
the line info tables. This manifests as an inability to set a breakpoint on
certain source positions. I have tested this on gdb version 8.3, and on current
To reproduce, load the attached executable in gdb, and run the command "break
The behaviour I would expect is for a breakpoint to be set at address 0x11bc.
The actual behaviour is that a breakpoint is set at address 0x11e0,
corresponding to line is_stmt_bp.c:16 which is in a different function.
I observe that the Line Info in the dwarf for this executable does contain an
entry associating line with address. The output of "objdump --dwarf" contains:
[0x0000013e] Special opcode 75: advance Address by 5 to 0x11bc and Line by 0
[0x0000013f] Set Filename to entry 1 in the File Name Table
[0x00000141] Set column to 5
[0x00000143] Set is_stmt to 1
[0x00000144] Advance Line by -97 to 10
[0x00000147] Copy (view 1)
(Filename entry 1 being is_stmt_bp.c)
However, this is immediately followed by a switch into another file (entry 2 is
[0x00000148] Set Filename to entry 2 in the File Name Table
[0x0000014a] Set column to 1
[0x0000014c] Advance Line by 95 to 105
[0x0000014f] Copy (view 2)
[0x00000150] Set column to 3
[0x00000152] Special opcode 7: advance Address by 0 to 0x11bc and Line by 2
to 107 (view 3)
[0x00000153] Set column to 10
[0x00000155] Set is_stmt to 0
[0x00000156] Copy (view 4)
When lnp_state_machine::record_line() determines that the file has changed, it
inserts an end marker into the first file. This causes
buildsym_compunit::record_line() to overwrite the line for is_stmt_bp.c:10.
There is already some code which attempts to preserve an existing line entry if
is_stmt=1 in the existing line and is_stmt=0 in the following entry. But in
this example is_stmt=1 for both the line in is_stmt_bp.c and also the line in
I do not think that having both entries set is_stmt ought to be considered
invalid? My understanding is that setting is_stmt in an indication that the
current instruction address is the best association for a given source line -
and makes no claim that the current source line is the best association for a
given instruction address.
The executable was built using the system compiler for Ubuntu 19.10, using the
gcc is_stmt_bp.c -o is_stmt_bp.exe -O2 -g
Here are the details of that system and compiler:
$ uname -a
Linux aws-ubuntu-19-10-skylake-x64-acollier 5.3.0-1030-aws #32-Ubuntu SMP Tue
Jun 30 21:48:50 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ gdb --version
GNU gdb (GDB) 10.0.50.20200730-git
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ gdb --configuration
This GDB was configured as follows:
configure --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu