[PATCH v2] gdb/linespec: Improve sliding breakpoints

[Luis Machado]

On 9/10/24 15:55, Shahab Vahedi wrote:
> From: Lancelot SIX <lancelot.six@amd.com>
> 
> The algorithm used to place a breakpoint by line approximately goes as
> follow:
> 
> - Look for all the PCs which maps directly to the desired line
> - If any PC is found, place a breakpoint at each found PC.
> - If no PC maps to the desired line:
>   - Search for the lowest line number in the line table which is higher
>     than the desired line, and has some object code associated to it.
>   - List all PCs which map to this new line number.
>   - Place a breakpoint at each PC in the list above.
> 
> There are situations where this heuristic is not sufficient.  If we
> consider the following c++ code:
> 
>     12 template<typename T>
>     13 T func (T a, T b)
>     14 {
>     15   /* Break here.  */
>     16   if constexpr (std::is_integral_t<T>)
>     17     return a;
>     18   else
>     19     return b;
>     20 }
> 
> Given the current algorithm, if the user tries to set a breakpoint at
> line 15, here is what happens:
> 
> - Search PCs mapping to L15, there is none ;
> - Search for the first line number above L15 with code, this is L17 ;
> - List all PCs mapping to L17 and a breakpoints at insert a breakpoint at
>   each ;
> 
> Now lets suppose that this templated function has been instantiated both
> for an integral type (int) and non-integral type (float).  If we follow
> the algorithm, no breakpoint will ever be inserted in func<float>,
> while there will be a breakpoint in func<int>.
> 
> I came across a less obvious variation of this case where an inlined
> function had different optimization opportunities for different instances.
> As a consequence, some instances had the first actual line of code
> different than the other, making the breakpoint be missed and the user
> confused.

Out of curiosity, how much of this issue is down to the generated debug info not
depicting things in a more precise way?

Also, in practical terms, why would we place a breakpoint at 15 when 16 would be
a better option?

We also have rbreak for pattern-based breakpoint insertion, which should hopefully
cover multiple instantiations of templates.