No description
4a46959e7b
... when that packed array is part of a discriminated record and one of the bounds is a discriminant. Consider the following code: type FUNNY_CHAR_T is (NUL, ' ', '"', '#', [etc]); type FUNNY_STR_T is array (POSITIVE range <>) of FUNNY_CHAR_T; pragma PACK (FUNNY_STR_T); type FUNNY_STRING_T (SIZE : NATURAL := 1) is record STR : FUNNY_STR_T (1 .. SIZE) := (others => '0'); LENGTH : NATURAL := 4; end record; TEST: FUNNY_STRING_T(100); GDB is able to print the value of variable "test" and "test.str". But not "test.str(1)": (gdb) p test $1 = (size => 100, str => (33 'A', nul <repeats 99 times>), length => 1) (gdb) p test.str $2 = (33 'A', nul <repeats 99 times>) (gdb) p test.str(1) object size is larger than varsize-limit The problem occurs during the phase where we are trying to resolve the expression subscript operation. On the one hand of the subscript operator, we have the result of the evaluation of "test.str", which is our packed array. We have the following code to handle packed arrays in particular: if (ada_is_constrained_packed_array_type (desc_base_type (value_type (argvec[0])))) argvec[0] = ada_coerce_to_simple_array (argvec[0]); This eventually leads to a call to constrained_packed_array_type to return the "simple array". This function relies on a parallel ___XA type, when available, to determine the bounds. In our case, we find type... failure__funny_string_t__T4b___XA" ... which has one field describing the bounds of our array as: failure__funny_string_t__T3b___XDLU_1__size The part that interests us is after the ___XD suffix or, in other words: "LU_1__size". What this means in GNAT encoding parlance is that the lower bound is 1, and that the upper bound is the value of "size". "size" is our discriminant in this case. Normally, we would access the record's discriminant in order to get the upper bound's value, but we do not have that information, here. We are in a mode where we are just trying to "fix" the type without an actual value. This is what the call to to_fixed_range_type is doing, and because the fix'ing fails, it ends up returning the ___XDLU type unmodified as our index type. This shouldn't be a problem, except that the later part of constrained_packed_array_type then uses that index_type to determine the array size, via a call to get_discrete_bounds. The problem is that the upper bound of the ___XDLU type is dynamic (in the DWARF sense) while get_discrete_bounds implicitly assumes that the bounds are static, and therefore accesses them using macros that assume the bounds values are constants: case TYPE_CODE_RANGE: *lowp = TYPE_LOW_BOUND (type); *highp = TYPE_HIGH_BOUND (type); This therefore returns a bogus value for the upper bound, leading to an unexpectedly large size for our array, which later triggers the varsize-limit guard we've seen above. This patch avoids the problem by adding special handling of dynamic range types. It also extends the documentation of the constrained_packed_array_type function to document what happens in this situation. gdb/ChangeLog: * ada-lang.c (constrained_packed_array_type): Set the length of the return array as if both bounds where zero if that returned array's index type is dynamic. gdb/testsuite/ChangeLog: * gdb.ada/pkd_arr_elem: New Testcase. Tested on x86_64-linux. |
||
---|---|---|
bfd | ||
binutils | ||
config | ||
cpu | ||
elfcpp | ||
etc | ||
gas | ||
gdb | ||
gold | ||
gprof | ||
include | ||
intl | ||
ld | ||
libdecnumber | ||
libiberty | ||
opcodes | ||
readline | ||
sim | ||
texinfo | ||
.cvsignore | ||
.gitattributes | ||
.gitignore | ||
ChangeLog | ||
compile | ||
config-ml.in | ||
config.guess | ||
config.rpath | ||
config.sub | ||
configure | ||
configure.ac | ||
COPYING | ||
COPYING.LIB | ||
COPYING.LIBGLOSS | ||
COPYING.NEWLIB | ||
COPYING3 | ||
COPYING3.LIB | ||
depcomp | ||
djunpack.bat | ||
install-sh | ||
libtool.m4 | ||
ltgcc.m4 | ||
ltmain.sh | ||
ltoptions.m4 | ||
ltsugar.m4 | ||
ltversion.m4 | ||
lt~obsolete.m4 | ||
MAINTAINERS | ||
Makefile.def | ||
Makefile.in | ||
Makefile.tpl | ||
makefile.vms | ||
missing | ||
mkdep | ||
mkinstalldirs | ||
move-if-change | ||
README | ||
README-maintainer-mode | ||
setup.com | ||
src-release.sh | ||
symlink-tree | ||
ylwrap |
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.