aboutsummaryrefslogtreecommitdiff
path: root/bfd
diff options
context:
space:
mode:
authorThiago Jung Bauermann <thiago.bauermann@linaro.org>2024-08-25 20:34:13 -0300
committerThiago Jung Bauermann <thiago.bauermann@linaro.org>2024-09-05 01:02:51 -0300
commit43af2e08dc0af7796b557d14f13317c0c24f948a (patch)
treed43173382ad9a6a56a834a32f8b0f003a06b2143 /bfd
parent88327cbcd02807149450b42ded5949ae6ab845b7 (diff)
downloadgdb-43af2e08dc0af7796b557d14f13317c0c24f948a.zip
gdb-43af2e08dc0af7796b557d14f13317c0c24f948a.tar.gz
gdb-43af2e08dc0af7796b557d14f13317c0c24f948a.tar.bz2
gdbserver: aarch64: Fix expedited registers list
Since this commit: commit a8651ef51822f91ec86d0d5caffbf2e50b174c23 CommitDate: Fri Jun 14 14:47:38 2024 +0100 gdb/aarch64: prevent crash from in process agent gdbserver isn't sending expedited registers with its stop reply packets anymore. The problem is with how the constructor of the expedited_registers std::vector is called: The intent of the expedited_registers initialization in aarch64_linux_read_description is to create a vector with capacity for 6 elements, but that's not how the std::vector constructor works. Instead it creates a vector pre-populated with 6 elements initialized with the default value for the type of the elements, and thus the first 6 elements are null pointers. The actual expedited registers are added starting at the 7th element. This causes init_target_desc to consider that the expedite_regs list is empty, since it stops checking at the first nullptr element. The end result is that gdbserver doesn't send any expedited registers to GDB in its stop replies. Fix by not specifying an element count when declaring the vector. Tested for regressions on aarch64-linux-gnu native-extended-remote. Approved-By: Andrew Burgess <aburgess@redhat.com>
Diffstat (limited to 'bfd')
0 files changed, 0 insertions, 0 deletions