From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21369 invoked by alias); 5 Aug 2004 09:42:25 -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 21352 invoked from network); 5 Aug 2004 09:42:23 -0000 Received: from unknown (HELO server7.nfra.nl) (192.87.1.57) by sourceware.org with SMTP; 5 Aug 2004 09:42:23 -0000 Received: from juw15.nfra.nl [10.87.8.15] by server7.nfra.nl; Thu, 05 Aug 2004 11:42:22 +0200 Received: from juw15.nfra.nl (localhost [127.0.0.1]) by juw15.nfra.nl (8.12.2+Sun/8.11.1) with ESMTP id i759fNCu010170; Thu, 5 Aug 2004 11:41:23 +0200 (CEST) Received: (from kettenis@localhost) by juw15.nfra.nl (8.12.2+Sun/8.12.2/Submit) id i759fNJE010167; Thu, 5 Aug 2004 11:41:23 +0200 (CEST) Date: Thu, 05 Aug 2004 09:42:00 -0000 Message-Id: <200408050941.i759fNJE010167@juw15.nfra.nl> From: Mark Kettenis To: roland@redhat.com CC: cagney@gnu.org, gdb@sources.redhat.com In-reply-to: <200408041902.i74J2lTW024331@magilla.sf.frob.com> (message from Roland McGrath on Wed, 4 Aug 2004 12:02:47 -0700) Subject: Re: Identifying bottom-of-stack References: <200408041902.i74J2lTW024331@magilla.sf.frob.com> X-SW-Source: 2004-08/txt/msg00060.txt.bz2 Date: Wed, 4 Aug 2004 12:02:47 -0700 From: Roland McGrath On older architectures that worked before the advent of DWARF CFI, the outermost frame of new threads as no DWARF CFI at all and has the frame pointer register set to zero. I assume that GDB's idea of "CFA" in a frame without DWARF CFI is the value of the frame pointer register. I also assume that when the computed CFA is zero, GDB calls that "outermost". If these assumptions hold then there is no problem when the outermost frame has no CFI at all (and zeroes the frame pointer). Right? The problem is that a zero frame pointer is an insufficient condition to determine the bottom of the stack. With code generated with -fno-frame-pointer, the register that was traditionally used for the frame pointer can be used for other purposes, and may very well contain zero. On the x86-64, the code of the call that sets up the outermost frame (clone) has CFI but is careful to make sure that it doesn't cover the code that runs in the outermost frame of a new thread. That code clears its frame pointer before calling anyone. So except for a small window of the first few instructions a new thread runs before it's cleared its frame pointer, my theory says there shouldn't be a problem for x86-64. Is there one? There is. On amd64 -fno-frame-pointer is the default. So this effort of not generating CFI and clearing the framepointer is pointless. > - GLIBC marking those outermost frames with CFI indicating that both the > CFA and the RA are "unknown"? Andrew, please choose your wording carefully. We now have, "unspecified", "undefined", "unknown". It's all very much unclear what we mean by that. I'm very uncomfortable with using any of these.. Let's specify things in an explicit way if we're going to specify something at all. Mark