[PATCH 0/1] Fix block filter heuristic in linespec to preserve distinct code paths

[Klaus Gerlicher <klaus.gerlicher@intel.com>]

Hi all,

This series tries to address a shortcoming in the block filter heuristic in
linespec.c that causes breakpoints in vectorized loops to silently miss
execution paths.

What is wrong?
==============

When a compiler vectorizes a loop (with -O2 -ftree-vectorize on GCC or -O2 on
ICX), it emits two separate machine code regions for the same source line: a
vectorized body and a scalar remainder. Both have is_stmt entries in the DWARF
line table and live in the same function block. The original heuristic kept only
the first entry per block, discarding the scalar remainder. Consequently, when
the trip count is small enough to execute only the scalar path, the breakpoint
is never hit.

How to maybe fix it?
====================

The general idea is to analyze the instruction stream for branches—specifically,
backward branches  and unconditional exits. Instead of blindly keeping only the
first is_stmt entry per block, the fix now asks: "can execution fall through
from PC_A to PC_B in a straight line?" If not, the entriesrepresent distinct
code paths and both are preserved.

Two conditions indicate distinct code paths:
1. Unconditional exit: The last instruction before PC_B is an unconditional
   jmp or ret
2. Backward branch: Any instruction in the range is a relative branch whose
   target lies before PC_A (loop back-edge)

Notes
=====

A new gdbarch method gdbarch_insn_branch_target decodes the statically-known
target of relative branch instructions. It is currently implemented for amd64;
other architectures return a conservative default, preserving backward
compatibility. Architectures without instruction analysis support maintain the
original for-loop deduplication behavior, ensuring no regressions.

Testing
=======

The original heuristic had only one test case I found. Since compiler 
optimization generates complex code patterns, comprehensive test coverage now 
includes:

- for_loop_empty_body (-O0): Empty loop; expects 1 location
- for_loop_large_body (-O0): Large loop body exceeding former scan limits;
  expects 1 location
- for_loop_vectorized (-O2 -ftree-vectorize): Vectorized loop; expects ≥2
  locations with runtime reachability verification
- nested_vectorized_loops (-O2 -ftree-vectorize): Nested vectorization;
  expects ≥2 locations
- loop_with_early_break (-O2): Loop with conditional break; expects ≥2 or
  1 location
- ifelse_separate_lines (-O0): If-else with both branches on same line;
  expects 2 locations (sanity check for potential false merges)

All tests are built with both -O0 and -O2 -ftree-vectorize flags. Behavioral
tests validate that the tuning setting "set linespec-extended-block-filter off"
actually changes breakpoint resolution behavior.

Limitations
===========

This can naturally be extended arbitrarily with more knowledge about what
compilers emit, but it's a heuristic nonetheless. Current limitations include:

- Indirect branches are not analyzed (statically unknown targets)
- Only relative branch encodings are decoded
- Architecture support is limited to amd64 initially

- Tested with GCC 11 and ICX 2025.2 on x86_64

Klaus Gerlicher (1):
  gdb/linespec: relax block filter to preserve distinct code paths

 gdb/NEWS                                      |  11 +
 gdb/amd64-tdep.c                              |  57 ++++
 gdb/arch-utils.c                              |  10 +
 gdb/arch-utils.h                              |   1 +
 gdb/gdbarch-gen.c                             |  22 ++
 gdb/gdbarch-gen.h                             |  10 +
 gdb/gdbarch_components.py                     |  15 ++
 gdb/linespec.c                                |  95 ++++++-
 .../gdb.linespec/block-filter-cases.c         | 126 +++++++++
 .../gdb.linespec/block-filter-cases.exp       | 248 ++++++++++++++++++
 10 files changed, 592 insertions(+), 3 deletions(-)
 create mode 100644 gdb/testsuite/gdb.linespec/block-filter-cases.c
 create mode 100644 gdb/testsuite/gdb.linespec/block-filter-cases.exp

-- 
2.34.1

Intel Deutschland GmbH
Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany
Tel: +49 89 991 430, www.intel.de
Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell
Chairperson of the Supervisory Board: Nicole Lau
Registered Seat: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928