From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16457 invoked by alias); 24 Jan 2008 14:45:51 -0000 Received: (qmail 16445 invoked by uid 22791); 24 Jan 2008 14:45:48 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 24 Jan 2008 14:45:31 +0000 Received: (qmail 32542 invoked from network); 24 Jan 2008 14:45:28 -0000 Received: from unknown (HELO ?192.168.0.100?) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 24 Jan 2008 14:45:28 -0000 Message-ID: <4798A47E.3050306@codesourcery.com> Date: Thu, 24 Jan 2008 14:56:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.13pre) Gecko/20071023 Thunderbird/1.5.0.14pre Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Jim Blandy , gdb-patches Subject: Re: arm_addr_bits_remove References: <47965D31.3040602@codesourcery.com> <8f2776cb0801221525w1d26661dgf6452f876197a591@mail.gmail.com> <479752C8.8030201@portugalmail.pt> <8f2776cb0801231121r3fe9aea0q6f3c3d6887fcb251@mail.gmail.com> <20080123192842.GA22477@caradoc.them.org> <8f2776cb0801231311o19c31781h8a4663c405bcd22b@mail.gmail.com> <479819E2.1030603@portugalmail.pt> <8f2776cb0801232227n64502d4akef4642b051e77772@mail.gmail.com> <4798871B.4080207@codesourcery.com> <20080124133844.GA15771@caradoc.them.org> In-Reply-To: <20080124133844.GA15771@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00584.txt.bz2 Daniel Jacobowitz wrote: > > If you're daring enough, this is OK - this could affect any target > defining gdbarch_addr_bits_remove so keep an eye out in case hppa, > m88k, mips, or s390 break. Please wait another day before checking it > in, in case someone else knows more about it. > It seems possible that the hppa port would be affected. It has has a comment mentioning symbol tables having special bits set and other compilers other than gcc. From the comments, I believe the other ports would be safe -- the extra bits should be set at runtime only. Other than arm, only mips choses what to strip based on some expression, but in that case, the I believe the extra bits won't be set on the symbol tables/line info. > I think the original patch should be committed too. Jim objected in > terms of "returning the wrong answer", but that's not really the case. > The 0x2 bit is never an extra piece of information about an address, > like the 0x1 bit is. It's part of the address; just if it happens > to be part of an ARM address, executing code there is unpredictable. Since Jim didn't really object, I'll go with the original arm-tdep.c patch. -- Pedro Alves