aboutsummaryrefslogtreecommitdiff
path: root/gdb/python/python.c
diff options
context:
space:
mode:
authorTom Tromey <tromey@adacore.com>2025-05-13 13:41:26 -0600
committerTom Tromey <tromey@adacore.com>2025-05-15 06:51:19 -0600
commit9b026264097aa5f328a2d23f985fde961b41ef2e (patch)
tree09ff8ee4df4cb8a04ca0c700b4d238d5db840907 /gdb/python/python.c
parent27ba92a50c7abbfebf9f1fbc539c39f0011d2fd7 (diff)
downloadbinutils-9b026264097aa5f328a2d23f985fde961b41ef2e.zip
binutils-9b026264097aa5f328a2d23f985fde961b41ef2e.tar.gz
binutils-9b026264097aa5f328a2d23f985fde961b41ef2e.tar.bz2
Fix regression with dynamic array bounds
Kévin discovered that commit ba005d32b0f ("Handle dynamic field properties") regressed a test in the internal AdaCore test suite. The problem here is that, when writing that patch, I did not consider the case where an array type's bounds might come from a member of a structure -- but where the array is not defined in the structure's scope. In this scenario the field-resolution logic would trip this condition: /* Defensive programming in case we see unusual DWARF. */ if (fi == nullptr) return nullptr; This patch reworks this area, partly backing out that commit, and fixes the problem. In the new code, I chose to simply duplicate the field's location information. This isn't totally ideal, in that it might result in multiple copies of a baton. However, this seemed nicer than tracking the DIE/field correspondence for every field in every CU -- my thinking here is that this particular dynamic scenario is relatively rare overall. Also, if the baton cost does prove onerous, we could intern the batons somewhere. Regression tested on x86-64 Fedora 41. I also tested this using the AdaCore internal test suite. Tested-By: Simon Marchi <simon.marchi@efficios.com>
Diffstat (limited to 'gdb/python/python.c')
0 files changed, 0 insertions, 0 deletions