mirror of
https://github.com/bminor/binutils-gdb.git
synced 2025-12-29 18:41:27 +00:00
67ea24cb99
This patch started when I looked at this bit in cli/cli-cmds.c:
if (*(char **) cmd->var)
return value_cstring (*(char **) cmd->var, strlen (*(char **) cmd->var),
builtin_type (gdbarch)->builtin_char);
else
return value_cstring ("", 1,
builtin_type (gdbarch)->builtin_char);
I found it odd that the first value_cstring call passes a length that
does not consider the null terminator of the C string, but second does.
I want to clarify the documentation of value_cstring and fix the one
that is wrong.
Debugging a little bit, I found that the first call is the wrong one.
Doing:
(gdb) set args foo
(gdb) print $_gdb_setting("args")
$1 = "foo"
creates a struct value of code TYPE_CODE_ARRAY of size 3, which doesn't
have a null terminator. That does not create a valid C string. It is
however printed correctly by GDB, because the printing code makes sure
not to read past the value's length.
A way to expose the bug is to print each element of the created string,
including the null terminator. Before:
(gdb) set args foo
(gdb) p $_gdb_setting("args")[3]
no such vector element
After:
(gdb) set args foo
(gdb) p $_gdb_setting("args")[3]
$1 = 0 '\000'
Another perhaps more convincing way of showing the bug is if the string
value is passed to an inferior function call;
(gdb) print an_inferior_function($_gdb_setting("args))
The space allocate for the string in the inferior will not take into
account a null terminator (with the string "foo", 3 bytes will be
allocated). If the inferior tries to read the string until the null
terminator, it will read past the allocated buffer. Compiling the
inferior with AddressSanitizer makes that bad access obvious.
I found a few calls to value_cstring that were wrong, I fixed them
all, all exercised by the test.
The change in guile/scm-math.c maybe requires a bit of explanation.
According to the doc of gdbscm_scm_to_string, if don't pass a length
pointer, we get back a null-terminated string. If we pass a length
pointer, we get a non-null-terminated string, but we get the length
separately. Trying to pass "len + 1" to value_cstring would lead to GDB
reading past the allocated buffer, that is exactly of length `len`. So
instead, don't pass a length pointer and use strlen on the result.
gdb.base/settings.exp and gdb.python/py-mi.exp required changes in some
expected outputs, because the array type created by $_gdb_setting_str
is now one element larger, to account for the null terminator. I don't
think this change in user-visible behavior is a problem.
Change-Id: If8dd13cce55c70521e34e7c360139064b4e87496
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.