From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7095 invoked by alias); 24 Jan 2008 17:51:47 -0000 Received: (qmail 7087 invoked by uid 22791); 24 Jan 2008 17:51:46 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.183) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 24 Jan 2008 17:51:29 +0000 Received: by py-out-1112.google.com with SMTP id v53so384681pyh.33 for ; Thu, 24 Jan 2008 09:51:26 -0800 (PST) Received: by 10.35.86.19 with SMTP id o19mr1077093pyl.9.1201197085842; Thu, 24 Jan 2008 09:51:25 -0800 (PST) Received: by 10.35.36.15 with HTTP; Thu, 24 Jan 2008 09:51:25 -0800 (PST) Message-ID: <8f2776cb0801240951h9d8e948k9351cc5f2876c16b@mail.gmail.com> Date: Thu, 24 Jan 2008 21:33:00 -0000 From: "Jim Blandy" To: "Joel Brobecker" Subject: Re: arm_addr_bits_remove Cc: "Mark Kettenis" , pedro_alves@portugalmail.pt, gdb-patches@sourceware.org In-Reply-To: <20080124171757.GE3979@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> <200801241657.m0OGvlFA002413@brahms.sibelius.xs4all.nl> <20080124171757.GE3979@adacore.com> X-Google-Sender-Auth: f5625dd50fc56f64 X-IsSubscribed: yes 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/msg00591.txt.bz2 On Jan 24, 2008 9:17 AM, Joel Brobecker wrote: > > It would need some careful testing though, at least on RISCy targets. > > 2001 is quite a while ago and while the change might have been made > > for arm in the first place, other targets might depend on it by now. > > I am currently testing on IRIX and PA/HPUX; at least we'll know > about these targets. Let's keep in mind that this is a fixup for bad line number information. The DWARF spec says that those values are addresses of instructions, not addresses with bits of type or state information stuffed in the low bits. Accomodation for this sort of lossage should have a limited lifetime, because they complicate maintenance and improvements.