mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-24 04:00:07 +08:00
6849c6a2b8
I noticed that a build of GDB with GCC + --enable-ubsan, testing
against GDBserver showed this GDB crash:
(gdb) PASS: gdb.trace/trace-condition.exp: trace: 0x00abababcdcdcdcd << 46 == 0x7373400000000000: advance to trace begin
tstart
../../src/gdb/valarith.c:1365:15: runtime error: left shift of 48320975398096333 by 46 places cannot be represented in type 'long int'
ERROR: GDB process no longer exists
GDB process exited with wait status 269549 exp9 0 1
UNRESOLVED: gdb.trace/trace-condition.exp: trace: 0x00abababcdcdcdcd << 46 == 0x7373400000000000: start trace experiment
The problem is that, "0x00abababcdcdcdcd << 46" is an undefined signed
left shift, because the result is not representable in the type of the
lhs, which is signed. This actually became defined in C++20, and if
you compile with "g++ -std=c++20 -Wall", you'll see that GCC no longer
warns about it, while it warns if you specify prior language versions.
While at it, there are a couple other situations that are undefined
(and are still undefined in C++20) and result in GDB dying: shifting
by a negative ammount, or by >= than the bit size of the promoted lhs.
For the latter, GDB shifts using (U)LONGEST internally, so you have to
shift by >= 64 bits to see it:
$ gdb --batch -q -ex "p 1 << -1"
../../src/gdb/valarith.c:1365:15: runtime error: shift exponent -1 is negative
$ # gdb exited
$ gdb --batch -q -ex "p 1 << 64"
../../src/gdb/valarith.c:1365:15: runtime error: shift exponent 64 is too large for 64-bit type 'long int'
$ # gdb exited
Also, right shifting a negative value is implementation-defined
(before C++20, after which it is defined). For this, I chose to
change nothing in GDB other than adding tests, as I don't really know
whether we need to do anything. AFAIK, most implementations do an
arithmetic right shift, and it may be we don't support any host or
target that behaves differently. Plus, this becomes defined in C++20
exactly as arithmetic right shift.
Compilers don't error out on such shifts, at best they warn, so I
think GDB should just continue doing the shifts anyhow too.
Thus:
- Adjust scalar_binop to avoid the undefined paths, either by adding
explicit result paths, or by casting the lhs of the left shift to
unsigned, as appropriate.
For the shifts by a too-large count, I made the result be what you'd
get if you split the large count in a series of smaller shifts.
Thus:
Left shift, positive or negative lhs:
V << 64
=> V << 16 << 16 << 16 << 16
=> 0
Right shift, positive lhs:
Vpos >> 64
=> Vpos >> 16 >> 16 >> 16 >> 16
=> 0
Right shift, negative lhs:
Vneg >> 64
=> Vneg >> 16 >> 16 >> 16 >> 16
=> -1
This is actually Go's semantics (the compiler really emits
instructions to make it so that you get 0 or -1 if you have a
too-large shift). So for that language GDB does the shift and
nothing else. For other C-like languages where such a shift is
undefined, GDB warns in addition to performing the shift.
For shift by a negative count, for Go, this is a hard error. For
other languages, since their compilers only warn, I made GDB warn
too. The semantics I chose (we're free to pick them since this is
undefined behavior) is as-if you had shifted by the count cast to
unsigned, thus as if you had shifted by a too-large count, thus the
same as the previous scenario illustrated above.
Examples:
(gdb) set language go
(gdb) p 1 << 100
$1 = 0
(gdb) p -1 << 100
$2 = 0
(gdb) p 1 >> 100
$3 = 0
(gdb) p -1 >> 100
$4 = -1
(gdb) p -2 >> 100
$5 = -1
(gdb) p 1 << -1
left shift count is negative
(gdb) set language c
(gdb) p -2 >> 100
warning: right shift count >= width of type
$6 = -1
(gdb) p -2 << 100
warning: left shift count >= width of type
$7 = 0
(gdb) p 1 << -1
warning: left shift count is negative
$8 = 0
(gdb) p -1 >> -1
warning: right shift count is negative
$9 = -1
- The warnings' texts are the same as what GCC prints.
- Add comprehensive tests in a new gdb.base/bitshift.exp testcase, so
that we exercise all these scenarios.
Change-Id: I8bcd5fa02de3114b7ababc03e65702d86ec8d45d
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.