diff options
author | Shahab Vahedi <shahab@synopsys.com> | 2021-07-16 16:49:15 +0200 |
---|---|---|
committer | Shahab Vahedi <shahab@synopsys.com> | 2021-07-26 14:34:01 +0200 |
commit | c9bd98593b785d9bf5f39c7aa74ed0226a23b830 (patch) | |
tree | 290b6b9add1408d1855454b00415462698ce9f53 /COPYING.LIB | |
parent | 0264bf6fe3028a89c9a6a7b49c489831eb33f506 (diff) | |
download | binutils-c9bd98593b785d9bf5f39c7aa74ed0226a23b830.zip binutils-c9bd98593b785d9bf5f39c7aa74ed0226a23b830.tar.gz binutils-c9bd98593b785d9bf5f39c7aa74ed0226a23b830.tar.bz2 |
gdb: Fix numerical field extraction for target description "flags"
The "val_print_type_code_flags ()" function is responsible for
extraction of fields for "flags" data type. These data types are
used when describing a custom register type in a target description
XML. The logic used for the extraction though is not sound:
unsigned field_len = TYPE_FIELD_BITSIZE (type, field);
ULONGEST field_val
= val >> (TYPE_FIELD_BITPOS (type, field) - field_len + 1);
TYPE_FIELD_BITSIZE: The bit length of the field to be extracted.
TYPE_FIELD_BITPOS: The starting position of the field; 0 is LSB.
val: The register value.
Imagine you have a field that starts at position 1 and its length
is 4 bits. According to the third line of the code snippet the
shifting right would become "val >> -2", or "val >> 0xfff...fe"
to be precise. That will result in a "field_val" of 0.
The correct extraction should be:
ULONGEST field_val = val >> TYPE_FIELD_BITPOS (type, field);
The rest of the algorithm that masks out the higher bits is OK.
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Diffstat (limited to 'COPYING.LIB')
0 files changed, 0 insertions, 0 deletions