| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This commit changes the output of 'show endian'. Here is a
session before this commit:
(gdb) show endian
The target endianness is set automatically (currently little endian)
(gdb) set endian big
The target is assumed to be big endian
(gdb) show endian
The target is assumed to be big endian
(gdb)
After this commit the session now looks like this:
(gdb) show endian
The target endianness is set automatically (currently little endian).
(gdb) set endian big
The target is set to big endian.
(gdb) show endian
The target is set to big endian.
(gdb)
The changes are:
1. Each line ends with '.', and
2. After setting the endianness GDB is now a little more assertive;
'target is set to' not 'target is assumed to be', the user did just
tell us after all!
|
|
This commit changes the output of 'show architecture'. Here is a
session before this commit:
(gdb) show architecture
The target architecture is set automatically (currently i386)
(gdb) set architecture mips
The target architecture is assumed to be mips
(gdb) show architecture
The target architecture is assumed to be mips
(gdb)
After this commit the session now looks like this:
(gdb) show architecture
The target architecture is set to "auto" (currently "i386").
(gdb) set architecture mips
The target architecture is set to "mips".
(gdb) show architecture
The target architecture is set to "mips".
(gdb)
The changes are:
1. The value is now enclosed in quotes,
2. Each line ends with '.', and
3. After setting the architecture GDB is now a little more
assertive; 'architecture is set to' not 'is assumed to be', the user
did just tell us after all!
gdb/ChangeLog:
* arch-utils.c (show_architecture): Update formatting of messages.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-osabi.exp: Update.
* gdb.arch/arm-disassembler-options.exp: Update.
* gdb.arch/powerpc-disassembler-options.exp: Update.
* gdb.arch/ppc64-symtab-cordic.exp: Update.
* gdb.arch/s390-disassembler-options.exp: Update.
* gdb.base/all-architectures.exp.tcl: Update.
* gdb.base/attach-pie-noexec.exp: Update.
* gdb.base/catch-syscall.exp: Update.
* gdb.xml/tdesc-arch.exp: Update.
|
|
ARC can use odd-even double register pairs in some selected
instructions. Although the GNU assembler doesn't allow even-odd
registers to be used, there may be cases when the disassembler is
presented with such situation. This patch add a test and detects such
cases.
opcodes/
2020-07-14 Claudiu Zissulescu <claziss@gmail.com>
* arc-dis.c (print_insn_arc): Detect and emit a warning when a
faulty double register pair is detected.
binutils/
2020-07-14 Claudiu Zissulescu <claziss@gmail.com>
* testsuite/binutils-all/arc/double_regs.s: New test.
* testsuite/binutils-all/arc/objdump.exp: Add the above test.
Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>
|
|
%db<n> is an AT&T invention; the Intel documentation and MASM have only
ever specified DRn (in line with CRn and TRn). (In principle gas also
shouldn't accept the names in Intel mode, but at least for now I've kept
things as they are. Perhaps as a first step this should just be warned
about.)
|
|
Rm (and hence OP_R()) can be dropped by making 'Z' force modrm.mod to 3
(for OP_E()) instead of ignoring it. While at it move 'Z' handling to
its designated place (after 'Y'; 'W' handling will be moved by a later
change).
Moves to/from TRn are illegal in 64-bit mode and thus get converted to
honor this at the same time (also getting them in line with moves
to/from CRn/DRn ModRM.mod handling wise). This then also frees up the L
macro.
|
|
Rdq, Rd, and MaskR can be replaced by Edq, Ed / Rm, and MaskE
respectively, as OP_R() doesn't enforce ModRM.mod == 3, and hence where
MOD matters but hasn't been decoded yet it needs to be anyway. (The case
of converting to Rm is temporary until a subsequent change.)
|
|
In this case there's no need to go through prefix_table[] at all - the
.prefix_requirement == PREFIX_OPCODE machinery takes care of this case
already.
A couple of further adjustments are needed though:
- Gv / Ev and alike then can't be used (needs to be Gdq / Edq instead),
- dq_mode and friends shouldn't lead to PREFIX_DATA getting set in
used_prefixes.
|
|
|
|
Starting glibc 2.30, unistd.h declares gettid (for _GNU_SOURCE).
This clashes with a static gettid in test source
clone-new-thread-event.c:
...
gdb compile failed, gdb.threads/clone-new-thread-event.c:46:1: error: \
static declaration of 'gettid' follows non-static declaration
46 | gettid (void)
| ^~~~~~
In file included from /usr/include/unistd.h:1170,
from gdb.threads/clone-new-thread-event.c:27:
/usr/include/bits/unistd_ext.h:34:16: note: previous declaration of 'gettid' \
was here
34 | extern __pid_t gettid (void) __THROW;
| ^~~~~~
...
Fix this by renaming the static gettid to local_gettid.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-14 Tom de Vries <tdevries@suse.de>
* gdb.threads/clone-new-thread-event.c (gettid): Rename to ...
(local_gettid): ... this.
(fn): Update.
|
|
The only valid (embedded or explicit) prefix being the data size one
(which is a fairly common pattern), avoid going through prefix_table[].
Instead extend the "required prefix" logic to also handle PREFIX_DATA
alone in a table entry, now used to identify this case. This requires
moving the (adjusted) ->prefix_requirement logic ahead of the printing
of stray prefixes, as the latter needs to observe the new setting of
PREFIX_DATA in used_prefixes.
Also add PREFIX_OPCODE on related entries when previously there was
mistakenly no decode step through prefix_table[].
|
|
A few cases were missed by 6df22cf64c93 ("x86: drop EVEX table entries
that can be served by VEX ones").
|
|
It was quite odd for the prior operand handling to have to clear this
flag for the actual operand handling to print nothing. Have the actual
operand handling determine whether the operand is actually present.
With this {d,q}_scalar_swap_mode become unused and hence also get dropped.
|
|
These are only used when VEX.L or EVEX.L'L have already been decoded,
and hence the "normal" length dependent name determination is quite
fine. Adjust a few enumerators to make clear that vex_len_table[] has
been consulted; be consistent and do so for all *f128 and *i128 insns
in one go.
|
|
This makes more visible what the two alternatives will be that result
from this macro.
|
|
Fold redundant case blocks and move the extra adjustments logic into
the single case block that actually needs it - there's no need to go
through the extra logic for all the other cases. Also utilize there that
vex.b cannot be set at this point, due to earlier logic. Reduce the
comment there, which was partly stale anyway.
|
|
Unlike the earlier ones these also need their operands adjusted. Replace
the (mis-described: there's nothing "scalar" here) {b,w}_scalar_mode by
a single new mode, with the actual unit width controlled by EVEX.W.
|
|
The operands don't allow disambiguating the insn in 64-bit mode, and
hence suffixes need to be emitted not just in AT&T mode. Achieve this
by re-using %LQ while dropping PCMPESTR_Fixup().
|
|
There's no reason to have two functions and two tables, when the AVX
functionality here is a proper superset of the SSE one.
|
|
MOVBE_Fixup() is entirely redundant with the S macro already used on the
mnemonics, leading to double suffixes in suffix-always mode. Drop the
function.
|
|
Just like other insns with GPR operands, CRC32 with only register
operands should not get a suffix added unless in suffix-always mode.
Do away with CRC32_Fixup() altogether, using other more generic logic
instead.
|
|
Unlike for non-zero values passed to USED_REX(), where rex_used gets
updated only when the respective bit was actually set in the encoding,
zero getting passed in is not further guarded, yet such a (potentially
"empty") REX prefix takes effect only when there are registers numbered
4 and up.
|
|
There's only a very limited set of modes that this function gets invoked
with - avoid it being more generic than it needs to be. This may, down
the road, allow actually doing away with the function altogether.
This eliminates a first improperly used "USED_REX (0)".
|
|
Various of the test expectations get adjusted later in this and a
subsequent series, so in order to avoid having to adjust more instances
than necessary fold respective test ILP32 expectations with their main
64-bit counterparts where they're identical anyway.
|
|
When building gdbserver with AddressSanitizer, I get this annoying
little leak when gdbserver exits:
==307817==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 14 byte(s) in 1 object(s) allocated from:
#0 0x7f7fd4256459 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x563bef981b80 in xmalloc /home/simark/src/binutils-gdb/gdbserver/../gdb/alloc.c:60
#2 0x563befb53301 in xstrdup /home/simark/src/binutils-gdb/libiberty/xstrdup.c:34
#3 0x563bef9d742b in handle_query /home/simark/src/binutils-gdb/gdbserver/server.cc:2286
#4 0x563bef9ed0b7 in process_serial_event /home/simark/src/binutils-gdb/gdbserver/server.cc:4061
#5 0x563bef9f1d9e in handle_serial_event(int, void*) /home/simark/src/binutils-gdb/gdbserver/server.cc:4402
#6 0x563befb0ec65 in handle_file_event /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:548
#7 0x563befb0f49f in gdb_wait_for_event /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:673
#8 0x563befb0d4a1 in gdb_do_one_event() /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:215
#9 0x563bef9e721a in start_event_loop /home/simark/src/binutils-gdb/gdbserver/server.cc:3484
#10 0x563bef9eb90a in captured_main /home/simark/src/binutils-gdb/gdbserver/server.cc:3875
#11 0x563bef9ec2c7 in main /home/simark/src/binutils-gdb/gdbserver/server.cc:3961
#12 0x7f7fd3330001 in __libc_start_main (/usr/lib/libc.so.6+0x27001)
SUMMARY: AddressSanitizer: 14 byte(s) leaked in 1 allocation(s).
This is due to the handling of unknown qsupported features in
handle_query. The `qsupported` vector is built, containing all the
feature names received from GDB. As we iterate on them, when we
encounter unknown ones, we move them at the beginning of the vector, in
preparation of passing this vector of unknown features down to the
target (which may know about them).
When moving these unknown features to other slots in the vector, we
overwrite other pointers without freeing them, which therefore leak.
An easy fix would be to add a `free` when doing the move. However, I
think this is a good opportunity to sprinkle a bit of automatic memory
management in this code.
So, use a vector of std::string which owns all the entries. And use a
separate vector (that doesn't own the entries) for the unknown ones,
which is then passed to target_process_qsupported.
Given that the `c_str` method of std::string returns a `const char *`,
it follows that process_stratum_target::process_qsupported must accept a
`const char **` instead of a `char **`. And while at it, change the
pointer + size paramters to use an array_view instead.
gdbserver/ChangeLog:
* server.cc (handle_query): Use std::vector of
std::string for `qsupported` vector. Use separate
vector for unknowns.
* target.h (class process_stratum_target) <process_qsupported>:
Change parameters to array_view of const char *.
(target_process_qsupported): Remove `count` parameter.
* target.cc (process_stratum_target::process_qsupported): Change
parameters to array_view of const char *.
* linux-x86-low.cc (class x86_target) <process_qsupported>:
Likewise.
Change-Id: I97f133825faa6d7abbf83a58504eb0ba77462812
|
|
|
|
The addition of an anchor for the "frame apply" command was causing
the HTML documentation to include files named both "frame-apply.html"
and "Frame-Apply.html", which collide on case-insensitive file
systems. This patch removes the redundant anchor and adjusts the two
xrefs to it.
2020-07-13 Paul Carroll <pcarroll@codesourcery.com>
PR gdb/25716
gdb/doc/
* gdb.texinfo (Frame Apply): Remove anchor for 'frame
apply' and adjust xrefs to it.
|
|
When testing on a remote host, source files from build are copied to
an arbitrary location on host. Tests that try to pattern-match host
pathnames against directory prefixes on build don't generally work.
2020-07-13 Sandra Loosemore <sandra@codesourcery.com>
gdb/testsuite/
* gdb.base/info_sources.exp: Skip directory match tests on
remote hosts.
|
|
When encoding a 32-bit offset, there is no need to sign-extend it to 64
bits since only the lower 32 bits are used.
* config/tc-i386.c (offset_in_range): Remove 32-bit sign
extension.
|
|
gdb.base/savedregs.exp fails to run with clang, because of:
gdb compile failed, /gdbtest/src/gdb/testsuite/gdb.base/savedregs.c:36:37:
warning: operator '<<' has lower precedence than '+'; '+' will be
evaluated first [-Wshift-op-parentheses]
return callee (a1 << a2 * a3 / a4 + a6 & a6 % a7 - a8) + done;
~~ ~~~~~~~~~~~~~^~~~
/gdbtest/build/gdb/testsuite/gdb.base/savedregs.c:36:37: note: place
parentheses around the '+' expression to silence this warning
return callee (a1 << a2 * a3 / a4 + a6 & a6 % a7 - a8) + done;
^
( )
1 warning generated.
This commit fixes it by adding the suggested parentheses.
gdb/testsuite/ChangeLog:
* gdb.base/savedregs.exp (caller): Use parentheses to
make expected expression evaluation ordering explicit.
|
|
gdb.arch/i386-sse.exp fails to run with clang, because of:
gdb compile failed, /gdbtest/src/gdb/testsuite/gdb.arch/i386-sse.c:56:40: warning:
passing 'int *' to parameter of type 'unsigned int *' converts between
pointers to integer types with different sign [-Wpointer-sign]
if (!x86_cpuid (1, NULL, NULL, NULL, &edx))
^~~~
/gdbtest/src/gdb/testsuite/../nat/x86-cpuid.h:35:41: note: passing
argument to parameter '__edx' here
unsigned int *__ecx, unsigned int *__edx)
^
1 warning generated.
Fix it by declaring edx unsigned.
gdb/testsuite/ChangeLog:
* gdb.arch/i386-sse.c (have_sse) <edx>: Make unsigned.
|
|
|
|
Clang fails to compile a number of files with the following warning:
indirection of non-volatile null pointer will be deleted, not trap
[-Wnull-dereference]. This commit qualifies the relevant pointers
with 'volatile'.
gdb/testsuite/ChangeLog:
* gdb.base/bigcore.c (main): Use a volatile pointer when
attempting to trigger a SIGSEGV.
* gdb.base/gcore-relro-pie.c (break_here): Likewise.
* gdb.base/gcore-tls-pie.c (break_here): Likewise.
* gdb.base/savedregs.c (thrower): Likewise.
* gdb.mi/mi-syn-frame.c (bar): Likewise.
|
|
Clang fails to compile gdb.base/vla-datatypes.c with the following
error: fields must have a constant size: 'variable length array in
structure' extension will never be supported. This commit factors
the affected tests out into a new testcase, vla-struct-fields.{exp,c},
which is skipped when the testcase is compiled using clang,
gdb/testsuite/ChangeLog:
* gdb.base/vla-datatypes.c (vla_factory): Factor out sections
defining and using VLA structure fields into...
* gdb.base/vla-struct-fields.c: New file.
* gdb.base/vla-datatypes.exp: Factor out VLA structure field
tests into...
* gdb.base/vla-struct-fields.exp: New file.
|
|
Tests just having "xfail: x86_64-*-cygwin" aren't good, since
presumably if a test fails on x86_64-cygwin then it also fails on
x86_64-*-pe* and x86_64-*-mingw*.
binutils/
* testsuite/lib/binutils-common.exp (is_pecoff_format): Accept
optional machine-os arg.
ld/
* testsuite/ld-scripts/default-script1.d: Don't skip, xfail
using is_pecoff_format.
* testsuite/ld-scripts/default-script2.d: Likewise.
* testsuite/ld-scripts/default-script3.d: Likewise.
* testsuite/ld-scripts/default-script4.d: Likewise.
* testsuite/ld-scripts/pr20302.d: Remove x86_64-*-cygwin from notarget.
* testsuite/ld-scripts/provide-6.d: Remove x86_64-*-cygwin from xfail.
* testsuite/ld-scripts/provide-8.d: Likewise.
|
|
git commit af2b318648 introduced a number of XPASSes. This removes
them. (It also introduces a FAIL on ft32-elf but the comment in the
.d file didn't adequately explain why the failure should be expected.)
* testsuite/gas/elf/dwarf2-7.d: Remove most xfails.
* testsuite/gas/elf/dwarf2-12.d: Likewise.
* testsuite/gas/elf/dwarf2-13.d: Likewise.
* testsuite/gas/elf/dwarf2-14.d: Likewise.
|
|
When running test-case gdb.base/morestack.exp without the gold linker
installed, we run into:
...
Running src/gdb/testsuite/gdb.base/morestack.exp ...
gdb compile failed, collect2: fatal error: cannot find 'ld'
compilation terminated.
FAIL: gdb.base/morestack.exp: continue
=== gdb Summary ===
nr of expected passes 1
nr of unexpected failures 1
nr of untested testcases 1
...
The test-case needs the gold linker to run correctly (as explained in commit
b8d38ee425 "testsuite: Fix false FAIL for gdb.base/morestack.exp"), but
only prefers it, and doesn't require it.
Fix this by requiring the gold linker in the test-case. Furthermore, silence
the compilation error by introducing a caching proc have_fuse_ld_gold and
using it in this and other test-cases that use -fuse-ld=gold.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-13 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (have_fuse_ld_gold): New caching proc.
* gdb.base/gcore-tls-pie.exp: Use have_fuse_ld_gold.
* gdb.base/gold-gdb-index.exp: Same.
* gdb.base/morestack.exp: Same.
|
|
Getting the bounds of an array (or string) type is a common operation,
and is currently done through its index type:
my_array_type->index_type ()->bounds ()
I think it would make sense to let the `type::bounds` methods work for
arrays and strings, as a shorthand for this. It's natural that when
asking for the bounds of an array, we get the bounds of the range type
used as its index type. In a way, it's equivalent as the now-removed
TYPE_ARRAY_{LOWER,UPPER}_BOUND_IS_UNDEFINED and
TYPE_ARRAY_{LOWER,UPPER}_BOUND_VALUE, except it returns the
`range_bounds` object. The caller is then responsible for getting the
property it needs in it.
I updated all the spots I could find that could take advantage of this.
Note that this also makes `type::bit_stride` work on array types, since
`type::bit_stride` uses `type::bounds`. `my_array_type->bit_stride ()`
now returns the bit stride of the array's index type. So some spots
are also changed to take advantage of this.
gdb/ChangeLog:
* gdbtypes.h (struct type) <bounds>: Handle array and string
types.
* ada-lang.c (assign_aggregate): Use type::bounds on
array/string type.
* c-typeprint.c (c_type_print_varspec_suffix): Likewise.
* c-varobj.c (c_number_of_children): Likewise.
(c_describe_child): Likewise.
* eval.c (evaluate_subexp_for_sizeof): Likewise.
* f-typeprint.c (f_type_print_varspec_suffix): Likewise.
(f_type_print_base): Likewise.
* f-valprint.c (f77_array_offset_tbl): Likewise.
(f77_get_upperbound): Likewise.
(f77_print_array_1): Likewise.
* guile/scm-type.c (gdbscm_type_range): Likewise.
* m2-typeprint.c (m2_array): Likewise.
(m2_is_long_set_of_type): Likewise.
* m2-valprint.c (get_long_set_bounds): Likewise.
* p-typeprint.c (pascal_type_print_varspec_prefix): Likewise.
* python/py-type.c (typy_range): Likewise.
* rust-lang.c (rust_internal_print_type): Likewise.
* type-stack.c (type_stack::follow_types): Likewise.
* valarith.c (value_subscripted_rvalue): Likewise.
* valops.c (value_cast): Likewise.
Change-Id: I5c0c08930bffe42fd69cb4bfcece28944dd88d1f
|
|
Remove it and update all callers to use the equivalent accessor methods.
A subsequent patch will make type::bit_stride work for array types
(effectively replacing this macro), but I wanted to keep this patch a
simple mechanical change.
gdb/ChangeLog:
* gdbtypes.c (TYPE_ARRAY_BIT_STRIDE): Remove. Update all
callers to use the equivalent accessor methods.
Change-Id: I09e14bd45075f98567adce8a0b93edea7722f812
|
|
Remove the macro and add a `bit_stride` method to `struct range_bounds`,
which does the byte -> bit conversion if needed.
Add a convenience `bit_stride` method to `struct type` as well. I don't
really understand why the bit/byte stride is stored in the data
structure for bounds. Maybe it was just put there because
`range_bounds` was already a data structure specific to TYPE_CODE_RANGE
types? If the stride is indeed not related to the bounds, then I find
it more logical to do `my_range_type->bit_stride ()` than
`my_range_type->bounds ()->bit_stride ()`, hence the convenience
function on `struct type`.
gdb/ChangeLog:
* gdbtypes.h (struct range_bounds) <bit_stride>: New method.
(struct type) <bit_stride>: New method.
(TYPE_BIT_STRIDE): Remove.
* gdbtypes.c (update_static_array_size): Use type::bit_stride.
Change-Id: I6ecc1cfefdc20711fa8f188a94a05c1e116c9922
|
|
Remove the macros, use the various equivalent getters instead.
gdb/ChangeLog:
* gdbtypes.h (TYPE_ARRAY_LOWER_BOUND_VALUE,
TYPE_ARRAY_UPPER_BOUND_VALUE): Remove. Update all
callers to use the equivalent accessor methods instead.
Change-Id: I7f96d988f872170e7a2f58095832710e62b85cfd
|
|
Remove the macros, use the various equivalent getters instead.
gdb/ChangeLog:
* gdbtypes.h (TYPE_ARRAY_UPPER_BOUND_IS_UNDEFINED,
TYPE_ARRAY_LOWER_BOUND_IS_UNDEFINED): Remove. Update all
callers to use the equivalent accessor methods instead.
Change-Id: Ifb4c36f440b82533bde5d15a5cbb2fc91f467292
|
|
Remove the macros, use the getters of `struct dynamic_prop` instead.
gdb/ChangeLog:
* gdbtypes.h (TYPE_LOW_BOUND_KIND,
TYPE_HIGH_BOUND_KIND): Remove. Update all callers
to use dynamic_prop::kind.
Change-Id: Icb1fc761f675bfac934209f8102392504d905c44
|
|
Remove the macros, use the getters of `struct dynamic_prop` instead.
gdb/ChangeLog:
* gdbtypes.h (TYPE_LOW_BOUND_UNDEFINED,
TYPE_HIGH_BOUND_UNDEFINED): Remove. Update all callers
to get the bound property's kind and check against
PROP_UNDEFINED.
Change-Id: I6a7641ac1aa3fa7fca0c21f00556f185f2e2d68c
|
|
Remove the macros, use the getters of `struct dynamic_prop` instead.
gdb/ChangeLog:
* gdbtypes.h (TYPE_LOW_BOUND, TYPE_HIGH_BOUND): Remove. Update
all callers to use type::range_bounds followed by
dynamic_prop::{low,high}.
Change-Id: I31beeed65d94d81ac4f999244a8b859e2ee961d1
|
|
Add setters, to ensure that the kind and value of the property are
always kept in sync (a caller can't forget one or the other). Add
getters, such that we can assert that when a caller accesses a data bit
of the property, the property is indeed of the corresponding kind.
Note that because of the way `struct dynamic_prop` is allocated
currently, we can't make the `m_kind` and `m_data` fields private. That
would make the type non-default-constructible, and we would have to call
the constructor when allocating them. However, I still prefixed them
with `m_` to indicate that they should not be accessed from outside the
class (and also to be able to use the name `kind` for the method).
gdb/ChangeLog:
* gdbtypes.h (struct dynamic_prop) <kind, set_undefined,
const_val, set_const_val, baton, set_locexpr, set_loclist,
set_addr_offset, variant_parts, set_variant_parts,
original_type, set_original_type>: New methods.
<kind>: Rename to...
<m_kind>: ... this. Update all users to use the new methods
instead.
<data>: Rename to...
<m_data>: ... this. Update all users to use the new methods
instead.
Change-Id: Ib72a8eb440dfeb1a5421d0933334230d7f2478f9
|
|
The next patch adds getters to the `dynamic_prop` structure. These
getters validate that the accessed data matches the property kind (for
example, to access the `const_val` field, the property must be of kind
`PROP_CONST`). It found one instance where we are accessing the
`const_val` data of a property that has the undefined kind.
This happens in function `get_discrete_bounds`, and is exposed by test
gdb.base/ptype.exp, amongst others. Without this patch, we would get:
$ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.base/ptype/ptype -ex "ptype t_char_array"
Reading symbols from testsuite/outputs/gdb.base/ptype/ptype...
type = char [
/home/smarchi/src/binutils-gdb/gdb/gdbtypes.h:526: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
The `get_discrete_bounds` function returns the bounds of a type (not
only range types). For range types, it naturally uses the bound
properties that are intrinsic to the range type. It accesses these
properties using TYPE_LOW_BOUND and TYPE_HIGH_BOUND, which assume the
properties are defined and have constant values. This is sometimes not
the case, and the passed range type (as in the example above) has an
undefined high/upper bound.
Given its current interface (returning two LONGEST values for low and
high), `get_discrete_bounds` can't really work if the range type's
bounds are not both defined and both constant values.
This patch changes the function to return -1 (failure to get the bounds)
if any of the range type's bounds is not a constant value. It is
sufficient to fix the issue and it seems to keep the callers happy, at
least according to the testsuite.
A bit in `get_array_bounds` could be removed, since
`get_discrete_bounds` no longer returns 1 if a bound is undefined.
gdb/ChangeLog:
* gdbtypes.c (get_discrete_bounds): Return failure if
the range type's bounds are not both defined and constant
values.
(get_array_bounds): Update comment. Remove undefined bound check.
Change-Id: I047a3beee2c1e275f888cfc4778228339922bde9
|
|
Remove it in favor of using type::bounds directly.
gdb/ChangeLog:
* gdbtypes.h (TYPE_RANGE_DATA): Remove. Update callers to use
the type::bounds method directly.
Change-Id: Id4fab22af0a94cbf505f78b01b3ee5b3d682fba2
|
|
Add the `bounds` and `set_bounds` methods on `struct type`, in order to
remove the `TYPE_RANGE_DATA` macro. In this patch, the
`TYPE_RANGE_DATA` macro is changed to use `type::bounds`, so all the
call sites that are used to set a range type's bounds are changed to use
`type::set_bounds`. The next patch will remove `TYPE_RANGE_DATA`
completely.
gdb/ChangeLog:
* gdbtypes.h (struct type) <bounds, set_bounds>: New methods.
(TYPE_RANGE_DATA): Use type::bounds. Change all uses that
are used to set the range type's bounds to use set_bounds.
Change-Id: I62e15506239b98404e62bbea8120db184ed87847
|
|
|
|
|
