gdb/cuda: add SASS listing breakpoints

[Tyxiaoyou]

Summary

This patch adds a CUDA-GDB workflow for setting breakpoints on numbered SASS
listings without manually computing runtime device addresses.

New user-facing commands:

(cuda-gdb) sass KERNEL
(cuda-gdb) break -sass KERNEL:NUMBER
(cuda-gdb) break -sass KERNEL+OFFSET

sass KERNEL prints a numbered SASS listing for a loaded CUDA
kernel/function. break -sass stores a symbolic SASS breakpoint selector
and resolves it to ordinary CUDA device breakpoint locations when matching CUDA
modules are loaded.

Motivation

CUDA-GDB can already set source-level CUDA breakpoints and raw address
breakpoints. The missing workflow is a convenient way to break at a visible SASS
instruction. Today users must wait for the kernel/module to load, inspect SASS,
compute a runtime PC or offset manually, and set a raw address breakpoint.

This change keeps the internal breakpoint mechanism address-based while adding
a source-breakpoint-like CLI for SASS listings.

Implementation Notes

• Extends the CUDA disassembly cache with per-function SASS listing records:
  instruction number, SASS offset, runtime PC, and display text.
• Adds sass KERNEL in gdb/cuda/cuda-commands.c.
• Adds a CUDA-specific ordinary_breakpoint subclass for symbolic SASS
  breakpoints in gdb/breakpoint.c.
• Resolves pending SASS breakpoints during normal breakpoint_re_set() after
  CUDA module load.
• Uses the existing CUDA device breakpoint insertion and hit-detection path.
• Treats ambiguous matches within one module as an error requiring a more
  specific or mangled function name.

Validation

Tested on the official nvidia-gdb-16.3 branch with
examples/vector_add_debug.cu.

The branch was built with CUDA 13.3 Debugger headers extracted from the
NVIDIA cuda-gdb-13-3 package. Runtime smoke tests used CUDA 13.3 cuobjdump
and nvdisasm extracted from the matching NVIDIA packages.

Build:

make -j8 all-gdb

CLI registration was checked with:

./gdb/gdb --batch -ex "help sass" -ex "help break"

Runtime instruction-number test:

(cuda-gdb) break -sass vector_add_kernel:31
(cuda-gdb) run
(cuda-gdb) x/i $pc

The breakpoint hit:

<_Z17vector_add_kernelPKfS0_Pfi+480>: S2R R3,SR_TID.X

The offset form break -sass vector_add_kernel+0x1e0 hit the same SASS
instruction.

Listing test:

(cuda-gdb) set cuda break_on_launch application
(cuda-gdb) run
(cuda-gdb) sass vector_add_kernel

sass vector_add_kernel printed a numbered SASS listing and instruction
31 corresponded to offset 0x1e0.

Additional checks:

• git diff --check passes.
• break -sass vector_add_kernel+0x1e0 can be set before launch, remains
  pending, resolves after CUDA module load, and hits the same instruction as
  vector_add_kernel:31.
• break -sass vector_add_kernel:63 can be set after stopping at kernel entry
  with set cuda break_on_launch application, resolves immediately, and hits:

<_Z17vector_add_kernelPKfS0_Pfi+992>: LD.E R8,desc[UR4][R8.64]

• A pending break -sass vector_add_kernel:31 survives run a second time and
  resolves again to the current launch's runtime device PC.

Follow-Up Work

• Add regression tests for:
  • pending SASS breakpoint before launch;
  • immediate resolution after module load;
  • instruction-number form;
  • offset form;
  • ambiguous names;
  • invalid instruction number or offset.
• Consider MI/TUI integration after the CLI semantics settle.