From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24254 invoked by alias); 1 Jun 2003 10:00:55 -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 23959 invoked from network); 1 Jun 2003 10:00:44 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.212) by sources.redhat.com with SMTP; 1 Jun 2003 10:00:44 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p2/8.12.5) with ESMTP id h51A0arJ000422; Sun, 1 Jun 2003 12:00:36 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p2/8.12.6) with ESMTP id h51A0aTi006409; Sun, 1 Jun 2003 12:00:36 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p2/8.12.6/Submit) id h51A0aGA006406; Sun, 1 Jun 2003 12:00:36 +0200 (CEST) To: Richard Henderson Cc: gdb@sources.redhat.com Subject: Re: dwarf-frame.c question References: <20030601055751.GA12187@redhat.com> From: Mark Kettenis Date: Sun, 01 Jun 2003 10:00:00 -0000 In-Reply-To: Richard Henderson's message of "Sat, 31 May 2003 22:57:51 -0700" Message-ID: <86brxice2j.fsf@elgar.kettenis.dyndns.org> X-SW-Source: 2003-06/txt/msg00007.txt.bz2 Richard Henderson writes: > [ Pasted from web archives, sorry. ] > > Mark Kettenis: > > Andrew, it seems that we should tweak the frame code > > to make sure that frame_unwind_by_pc is always passed a PC *within* the > > function. > > Andrew Cagney: > > True, but how? It would effectively be frame_unwind_address_in_block() but > > how reliably/where could it be used? > > Careful; this silliness of subtracting one is not universal. > > ABI's with more thought in them (e.g. IA64) require the compiler > to put *something* after a noreturn call that ends a function. > This being a relatively uncommon case, it does not add much code > size, and it solves some of the ambiguity problems you're seeing. Note that it is not only noreturn calls that end a function that pose a problem. As Andrew and Alexandre pointed out, branch instructions pose a problem too. Do you think we should require (or politely ask ;-)) the compiler to put something after a noreturn call on other targets as well? Mark