From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5314 invoked by alias); 6 May 2014 01:42:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 5249 invoked by uid 48); 6 May 2014 01:41:54 -0000 From: "thomas.preudhomme at arm dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/60109] __builtin_frame_address does not work as documented on ARM Date: Tue, 06 May 2014 01:42:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: thomas.preudhomme at arm dot com X-Bugzilla-Status: RESOLVED 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: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-05/txt/msg00317.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60109 --- Comment #4 from Thomas Preud'homme --- Sorry for the late reply, I wasn't aware of this bug report until today. (In reply to Richard Earnshaw from comment #1) > This is an unresolvable problem. > > If we made __builtin_frame_address(N > 0) always return 0, then some useful > use cases for debugging would be excluded. > > On the other hand, it is impossible to know whether it will return a useful > value in other cases, since it is dependent on all code being: > a) built with the same instruction set (arm or thumb) Doesn't gcc use the same instruction set for a given compilation unit? I thought an application (without its libraries) would typically not mix instruction sets and therefore builtin_(return|frame)_address could be made to work within an application in 99% of the cases even if it breaks accross library calls (that could be compiled with different instruction set). > b) Having a consistent use of the frame pointer. It was my understanding that having a __builtin_frame_address disable frame pointer elimination base of the following comment in expand_builtin_return_addr (): "For a nonzero count, or a zero count with __builtin_frame_address, we require a stable offset from the current frame pointer to the previous one, so we must use the hard frame pointer, and we must disable frame pointer elimination." The fact that other compilation unit might not have a frame pointer because they were compiled with different compilers is ok. It would be nice that it works within a given compilation unit (as in the example in the initial email) though.