diff options
author | Tom de Vries <tdevries@suse.de> | 2025-01-10 10:32:00 +0100 |
---|---|---|
committer | Tom de Vries <tdevries@suse.de> | 2025-01-10 10:32:00 +0100 |
commit | 84067a55fcbb15f903c7298adc3a708c6a431e12 (patch) | |
tree | a5de032bc112d1a89702e886c07880bfd0deabd6 /gdb/riscv-tdep.c | |
parent | 52cb36ccb92e252eb37d4dcde8adbf34aab1caaa (diff) | |
download | binutils-84067a55fcbb15f903c7298adc3a708c6a431e12.zip binutils-84067a55fcbb15f903c7298adc3a708c6a431e12.tar.gz binutils-84067a55fcbb15f903c7298adc3a708c6a431e12.tar.bz2 |
[gdb/tdep] Fix gdb.cp/non-trivial-retval.exp on riscv64-linux
With test-case gdb.cp/non-trivial-retval.exp on riscv64-linux, I ran into:
...
(gdb) finish^M
Run till exit from #0 f1 (i1=i1@entry=23, i2=i2@entry=100) \
at non-trivial-retval.cc:34^M
main () at non-trivial-retval.cc:163^M
163 B b = f2 (i1, i2);^M
Value returned is $6 = {a = -5856}^M
(gdb) FAIL: $exp: finish from f1
...
where "Value returned is $6 = {a = 123}" is expected.
The problem is that gdb thinks that the return value is in $a0:
...
$ gdb -q -batch non-trivial-retval \
-ex "b f1" \
-ex run \
-ex "set debug riscv infcall on" \
-ex finish
Breakpoint 1 at 0x80a: file non-trivial-retval.cc, line 34.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/riscv64-linux-gnu/libthread_db.so.1".
Breakpoint 1, f1 (i1=i1@entry=23, i2=i2@entry=100) at non-trivial-retval.cc:34
34 {
[riscv-infcall] riscv_return_value: \
[R] type: 'A', length: 0x4, alignment: 0x4, register a0
[riscv-infcall] riscv_return_value: \
[R] type: 'A', length: 0x4, alignment: 0x4, register a0
[riscv-infcall] riscv_return_value: \
[R] type: 'A', length: 0x4, alignment: 0x4, register a0
main () at non-trivial-retval.cc:163
163 B b = f2 (i1, i2);
Value returned is $1 = {a = -3568}
...
while $a0 actually contains a pointer to the returned value 123:
...
(gdb) p /x $a0
$3 = 0x3ffffff210
(gdb) p *((unsigned int *)$a0)
$5 = 123
...
The returned type is:
...
class A
{
public:
A () {}
A (A &obj);
int a;
};
...
which is a C++ aggregate with a nontrivial (because it's user-defined) copy
constructor:
According to the ABI [1], indeed this is returned by reference:
...
Values are returned in the same manner as a first named argument of the same
type would be passed. If such an argument would have been passed by
reference, the caller allocates memory for the return value, and passes the
address as an implicit first parameter.
...
Aggregates larger than 2×XLEN bits are passed by reference and are replaced in
the argument list with the address, as are C++ aggregates with nontrivial copy
constructors, destructors, or vtables.
...
Fix this in riscv_call_arg_scalar_int by checking for
language_pass_by_reference ().trivially_copy_constructible.
The vtable case is explictly mentioned in the ABI, but AFAIU already covered
by the nontrivial copy constructor case.
The nontrivial destructor case is also not supported, but the testsuite
doesn't seem to trigger this.
Fix this by:
- extending the test-case to cover this scenario, and
- fixing it in riscv_call_arg_scalar_int by checking for
language_pass_by_reference ().trivially_destructible.
Tested on riscv64-linux.
PR tdep/32152
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32152
Approved-By: Andrew Burgess <aburgess@redhat.com>
[1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc
Diffstat (limited to 'gdb/riscv-tdep.c')
-rw-r--r-- | gdb/riscv-tdep.c | 6 |
1 files changed, 5 insertions, 1 deletions
diff --git a/gdb/riscv-tdep.c b/gdb/riscv-tdep.c index 932708c..200a20a 100644 --- a/gdb/riscv-tdep.c +++ b/gdb/riscv-tdep.c @@ -2857,8 +2857,12 @@ static void riscv_call_arg_scalar_int (struct riscv_arg_info *ainfo, struct riscv_call_info *cinfo) { + auto lang_req = language_pass_by_reference (ainfo->type); + if (TYPE_HAS_DYNAMIC_LENGTH (ainfo->type) - || ainfo->length > (2 * cinfo->xlen)) + || ainfo->length > (2 * cinfo->xlen) + || !lang_req.trivially_copy_constructible + || !lang_req.trivially_destructible) { /* Argument is going to be passed by reference. */ ainfo->argloc[0].loc_type |