From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32551 invoked by alias); 12 Dec 2006 15:39:59 -0000 Received: (qmail 32506 invoked by uid 22791); 12 Dec 2006 15:39:59 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 12 Dec 2006 15:39:53 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kBCFdb6g023861; Tue, 12 Dec 2006 10:39:37 -0500 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kBCFdYat010803; Tue, 12 Dec 2006 10:39:34 -0500 Received: from [192.168.7.77] (vpn-14-38.rdu.redhat.com [10.11.14.38]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id kBCFdXkJ028550; Tue, 12 Dec 2006 10:39:33 -0500 Message-ID: <457ECD2F.9050700@redhat.com> Date: Tue, 12 Dec 2006 15:39:00 -0000 From: Ulrich Drepper User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: Andrew Haley CC: Mark Kettenis , Jan Kratochvil , gcc@gcc.gnu.org, libc-alpha@sources.redhat.com, gdb@sourceware.org, Jakub Jelinek , Richard Henderson Subject: Re: Unwinding CFI gcc practice of assumed `same value' regs References: <20061211190300.GA4372@host0.dyn.jankratochvil.net> <17790.46246.634400.638852@zebedee.pink> <22844.82.92.89.47.1165935102.squirrel@webmail.xs4all.nl> <17790.50417.668957.495292@zebedee.pink> <457EC8BF.3040707@redhat.com> <17790.51754.814267.773596@zebedee.pink> In-Reply-To: <17790.51754.814267.773596@zebedee.pink> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00098.txt.bz2 Andrew Haley wrote: > Sure it does. Not breaking things is an excellent reason, probably > one of the the best reasons you can have. Nothing breaks if the responsible tools are updated in unison. > Really? Well, that's one interpretation. I don't believe that, > though. It's certainly an inconsistency in the specification, which > says that null-termination is supported, and this implies that you > can't put a zero in there. Again, this is just because the "authors" of the ABI didn't think. x86 has the same problem. ebp is freely used and not just for non-NULL values. Register's a scarce and I doubt you'll find any support introducing a register class which says that the register can only hold non-zero value. > "All of these" might be the right way to go. That is, keep > null-terminating the stack, strengthen the rules about what you might > do with %ebp, and extend debuginfo. The thread setup and the startup code certainly does initialize the register with zero. But this means nothing, the register can have zero values in all kinds of other places. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖