From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15994 invoked by alias); 13 Aug 2003 18:45:21 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 15964 invoked from network); 13 Aug 2003 18:45:19 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 13 Aug 2003 18:45:19 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 9DF452B7F; Wed, 13 Aug 2003 14:45:14 -0400 (EDT) Message-ID: <3F3A873A.9080100@redhat.com> Date: Wed, 13 Aug 2003 18:45:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Elizabeth Chastain Cc: gdb@sources.redhat.com Subject: Re: [Fwd: Unwinding through `no return'?] References: <200308131743.h7DHhRIL009378@duracef.shout.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-08/txt/msg00141.txt.bz2 > Three comments, kinda superficial: > > Sometimes the caller will be in code with no debug info, > such as library code. RA-1 would be good there. > > Look at the case where the operating system delivers a signal and sets > up a sigreturn frame. In that case, a return address on a stack > really does point to the first instruction of a function (__restore > on my red hat linux 8 box). RA-1 would be bad there. FYI, I've already sent a follow up expanding on this. > Someone, maybe rth?, mentioned that on some architectures, > the ABI requires a nop instruction after a noreturn call. > If we ask gcc to do something like that in all cases it might > make our job easier. That matches one of the responses: > Andrew: > > We also encountered this problem, where the call's return address actually > pointed to the first instruction of a subsequent routine, because the call > was known never to return. We were leery of changing the unwinder always to > back up because of the issue you raised, where a normal function call might > need different CFI before and after the call. I don't know of a real world > situation where that happens, but that doesn't mean there isn't one, and I'd > hate to break it. Our tail-wagging-dog solution was to emit an extra > instruction after the call that never returns. On Pentium, for instance, > ud2. Then that extra instruction's address was the return address and it had > CFI appropriate for the calling routine. > > -- Todd Allen Concurrent Computer Corporation But it won't fly when the compiler is trying to optimize for space. Andrew