[PATCH v2 2/2] scripts/gdb: Fix stack depot out-of-bounds diagnostic

[Ting-Han Hou <ue081723@gmail.com>]

The pool_index field was renamed to pool_index_plus_1, but the
out-of-bounds diagnostic in stack_depot_fetch() still accesses the old
field. Looking up a handle whose pool index is outside stack_pools
therefore raises "There is no member named pool_index" instead of
printing the diagnostic and returning an empty result.

Use the already decoded pool_index variable in the diagnostic.

Fixes: 9d938f40b228 ("scripts/gdb: rename pool_index to pool_index_plus_1")
Assisted-by: LLM
Signed-off-by: Ting-Han Hou <ue081723@gmail.com>
---
Changes in v2:
- No code change. Resent with git send-email as patch 2/2 of the
  series; the v1 posting was word-wrapped by the mail client and did
  not apply.

Tested the lx-stack_depot_lookup command with GDB 17.1 and a GCC-built
ELF fixture using the handle bitfield layout for 4 KiB pages. The
fixture contains one pool and a valid stack record. This is a synthetic
debugger fixture, not a booted kernel or a kernel core dump.

Handles 2 and 0xffff fail with the missing-member exception before the
fix and print the correct out-of-bounds diagnostic after it. Handle 1
still prints the expected instructions, and handle 0 retains its
existing rejection.

 scripts/gdb/linux/stackdepot.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/gdb/linux/stackdepot.py b/scripts/gdb/linux/stackdepot.py
index 37313a5a51a0..aaa18af25cd1 100644
--- a/scripts/gdb/linux/stackdepot.py
+++ b/scripts/gdb/linux/stackdepot.py
@@ -39,7 +39,7 @@ def stack_depot_fetch(handle):
 
     pool_index = parts['pool_index_plus_1'] - 1
     if pool_index >= pools_num:
-        gdb.write("pool index %d out of bounds (%d) for stack id 0x%08x\n" % (parts['pool_index'], pools_num, handle))
+        gdb.write("pool index %d out of bounds (%d) for stack id 0x%08x\n" % (pool_index, pools_num, handle))
         return gdb.Value(0), 0
 
     stack_pools = gdb.parse_and_eval('stack_pools')
-- 
2.53.0