From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id CC519385840D; Thu,  9 Feb 2023 18:39:31 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CC519385840D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1675967971;
	bh=j5K8T6FYqwrWlJcs53a9H6q/MUv4bqau+v36LuYQrxY=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=Ee4eAc4da/fTyrN+zQSPM/VNj1wS0eXXZS13C4oo7IvVDIm/5OBo2ecTYIsx+JoAn
	 1oTANObhMeqF0C6mY7cEA18jw8302gxF2XeOsH1WDbWtmd0mfqrMgGo5xmjvUwpN32
	 a/EATnCIhAE3rBzY4cmkfx4hWejB+VJ6OcQQ7cQU=
From: "tromey at sourceware dot org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug rust/30090] Using TUI on musl libc with Rust program, finish
 failed a bounds check
Date: Thu, 09 Feb 2023 18:39:31 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: rust
X-Bugzilla-Version: 12.1
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tromey at sourceware dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: tromey at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-30090-4717-L42vyxXex2@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-30090-4717@http.sourceware.org/bugzilla/>
References: <bug-30090-4717@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gdb-prs.sourceware.org>

https://sourceware.org/bugzilla/show_bug.cgi?id=3D30090

--- Comment #14 from Tom Tromey <tromey at sourceware dot org> ---
Ok, I think I'll just have to xfail the actual result here.
Basically, gdb has to rely on programs using the platform ABI
to extract return values.  However, my test function doesn't
seem to be doing this.

amd64-tdep.c thinks my type should be returned entirely in $rax, but
really it's being returned in a combo of $eax and $edx.

(gdb) disassemble return_some
Dump of assembler code for function
_ZN6finish11return_some17hc6e727e1fe11047cE:
   0x000055555555c400 <+0>:     push   %rax
   0x000055555555c401 <+1>:     movl   $0x61,0x4(%rsp)
   0x000055555555c409 <+9>:     movl   $0x1,(%rsp)
   0x000055555555c410 <+16>:    mov    (%rsp),%eax
   0x000055555555c413 <+19>:    mov    0x4(%rsp),%edx
^^^ here you can see eax/edx being set.
   0x000055555555c417 <+23>:    pop    %rcx
   0x000055555555c418 <+24>:    ret

(gdb) info regist
rax            0x1                 1
rbx            0x1                 1
rcx            0x6100000001        416611827713
rdx            0x61                97

The caller does:

   0x000055555555c420 <+0>:     sub    $0x18,%rsp
   0x000055555555c424 <+4>:     call   0x55555555c400
<_ZN6finish11return_some17hc6e727e1fe11047cE>
=3D> 0x000055555555c429 <+9>:     mov    %eax,0x8(%rsp)
   0x000055555555c42d <+13>:    mov    %edx,0xc(%rsp)

.. i.e., you can see it moving out of edx.

Now, arguably this is maybe some reading of the ABI.
amd64-tdep knows that rdx is the second integer register.
But, it seems to me that since the entire structure is 8
bytes, it should probably all be stuffed into rax.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=