diff options
author | Tom Tromey <tromey@adacore.com> | 2025-05-13 13:41:26 -0600 |
---|---|---|
committer | Tom Tromey <tromey@adacore.com> | 2025-05-15 06:51:19 -0600 |
commit | 9b026264097aa5f328a2d23f985fde961b41ef2e (patch) | |
tree | 09ff8ee4df4cb8a04ca0c700b4d238d5db840907 /gdb/python/python.c | |
parent | 27ba92a50c7abbfebf9f1fbc539c39f0011d2fd7 (diff) | |
download | binutils-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