[Bug breakpoints/26334] New: Line info not retained for some non-empty, is_stmt=1 lines

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[Bug breakpoints/26334] New: Line info not retained for some non-empty, is_stmt=1 lines

Sourceware - gdb-prs mailing list

            Bug ID: 26334
           Summary: Line info not retained for some non-empty, is_stmt=1
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: breakpoints
          Assignee: unassigned at sourceware dot org
          Reporter: acollier at undo dot io
  Target Milestone: ---

Created attachment 12744
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12744&action=edit
reproducer executable and source

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
git master.

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
to 107
  [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

$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.2.1-9ubuntu2'
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)

$ gdb --version
GNU gdb (GDB)
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
             --with-gdb-datadir=/home/acollier/.local/share/gdb (relocatable)
             --with-jit-reader-dir=/home/acollier/.local/lib/gdb (relocatable)

("Relocatable" means the directory can be moved with the GDB installation
tree, and GDB will still find it.)

You are receiving this mail because:
You are on the CC list for the bug.