From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id AAF91385B534; Tue,  7 Mar 2023 08:49:20 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AAF91385B534
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1678178960;
	bh=R0rlQ2nFEsFySYwdeiMbUb+LHqW7FQ+jT2jCX72U/4I=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=Lc2jVIKFLOQvvP0DcXnyw11OvYKpCAxx9WmQGoZFZIteNrJUfpQ44nJbXYruuSlI+
	 MmYEUAnmm5GE4t2hJ7QJVRb9vz3TqOcOljmrDSm+CEUGi8i7HWJXn51PwZ8HogOdaq
	 b+y8vZmdBO3A6Y7oWGLJ9pLtmOLJHVsX5LY5IiRU=
From: "uweigand at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/108996] Proposal for adding DWARF call site information
 in GCC with -O0
Date: Tue, 07 Mar 2023 08:49:20 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: debug
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: uweigand at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-108996-4-uHHKnEZAW7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108996-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108996-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108996

--- Comment #9 from Ulrich Weigand <uweigand at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Ulrich Weigand from comment #4)
> > (In reply to Jakub Jelinek from comment #3)
> > > What is done on other arches?
> >=20
> > That depends on the platform ABI.  On some arches, including x86/x86_64=
 and
> > arm/aarch64, the ABI requires the generated code reloads the return buf=
fer
> > pointer into a defined register at function exit (either the same it wa=
s in
> > on function entry, or some other ABI-defined register).  On those arche=
s,
> > GDB can at least inspect the return value at the point the function ret=
urn
> > happens.
>=20
> aarch64 does not require that. GCC produces it yes but that is a missed
> optimization, see PR 103010 which I filed against GCC for that case.

Well, I was looking at GDB code that at least *assumes* that the aarch64 ABI
does require that:
https://sourceware.org/git/?p=3Dbinutils-gdb.git;a=3Dblob;f=3Dgdb/aarch64-t=
dep.c;h=3D5b1b9921f87e588f8251a77d858f8f312be1e5ac;hb=3DHEAD#l2500

If this is incorrect, I guess GDB would have to be fixed.=