mirror of
https://github.com/bminor/binutils-gdb.git
synced 2025-11-16 12:34:43 +00:00
0e4fd060ee7244d00c76f0d4815063dfcc9877f1
PR tdep/33534 reports a regression due to commit 13f1820106 ("[gdb/tdep] Fix
inferior call return of small char array for ppc64 v1 abi").
The regression can be reproduced with the test-case introduced in the commit:
gdb.ada/return-small-char-array.exp, on a ppc64-linux setup with v1 elf abi
(cfarm121).
The commit contains two changes to a piece of code in
ppc64_sysv_abi_return_value:
...
/* Small character arrays are returned, right justified, in r3. */
- if (valtype->code () == TYPE_CODE_ARRAY
+ if (tdep->elf_abi == POWERPC_ELF_V1
+ && valtype->code () == TYPE_CODE_ARRAY
&& !valtype->is_vector ()
&& valtype->length () <= 8
- && valtype->target_type ()->code () == TYPE_CODE_INT
+ && (valtype->target_type ()->code () == TYPE_CODE_INT
+ || valtype->target_type ()->code () == TYPE_CODE_CHAR)
&& valtype->target_type ()->length () == 1)
...
The first change limits the effect of the if clause to the v1 elf abi. This
change doesn't affect the regression, since it's on a ppc64-linux setup with
v1 elf abi. Furthermore, it's correct in the sense that the v2 elf abi
doesn't have this kind of special treatment of small character arrays.
The second change is the part that causes the regression. The code itself
seems correct, in the sense that it enables gdb to recognize small char arrays
in ada.
The regression stems from the following discrepancy.
The comment in gdb states that "small character arrays are returned, right
justified, in r3". This matches the v1 ABI [1].
OTOH, gcc produces code that is not in agreement with this. Instead, it
passes the small character arrays in memory, in a caller-allocated storage
buffer pointed at by r3. This turns out to be an gcc bug [2].
Fix this by treating this as an abi spec bug, and replacing the code handling
the "Small character arrays" case with a comment.
Doing so reveals that there are two problems in the test-case:
- missing fvar-tracking, and
- the "step 2" command doesn't land at the intended line.
Fix these by:
- adding fvar-tracking, and
- setting a breakpoint at the intended line, and continuing to it.
Tested on ppc64-linux (v1 abi), ppc64le-linux (v2 abi), and x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33534
[1] https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html.
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122282
…
…
…
…
…
…
…
…
…
…
…
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, and so on. 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.
Description
Languages
C
50.5%
Makefile
22.7%
Assembly
13.2%
C++
5.9%
Roff
1.5%
Other
5.6%