From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11526 invoked by alias); 25 Jan 2008 22:51:39 -0000 Received: (qmail 11514 invoked by uid 22791); 25 Jan 2008 22:51:37 -0000 X-Spam-Check-By: sourceware.org Received: from hiauly1.hia.nrc.ca (HELO hiauly1.hia.nrc.ca) (132.246.100.193) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 25 Jan 2008 22:51:20 +0000 Received: from hiauly1.hia.nrc.ca (hiauly1.hia.nrc.ca [127.0.0.1] (may be forged)) by hiauly1.hia.nrc.ca (8.14.1/8.14.1) with ESMTP id m0PMp6P4012200; Fri, 25 Jan 2008 17:51:12 -0500 (EST) Received: (from dave@localhost) by hiauly1.hia.nrc.ca (8.14.1/8.14.1/Submit) id m0PMp6mt012198; Fri, 25 Jan 2008 17:51:06 -0500 (EST) Message-Id: <200801252251.m0PMp6mt012198@hiauly1.hia.nrc.ca> Subject: Re: arm_addr_bits_remove To: jimb@red-bean.com (Jim Blandy) Date: Sat, 26 Jan 2008 13:57:00 -0000 From: "John David Anglin" Cc: carlos@codesourcery.com, brobecker@adacore.com, pedro@codesourcery.com, gdb-patches@sourceware.org, dave.anglin@nrc.ca In-Reply-To: <8f2776cb0801251323h3283932dq96bb3aab41d0ca8c@mail.gmail.com> from "Jim Blandy" at Jan 25, 2008 01:23:38 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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/msg00622.txt.bz2 > On Jan 25, 2008 10:49 AM, John David Anglin wrote: > > Regarding symbol tables, I would have to check what the two bits are > > used for. What struct/bits? > > Within GDB, the debug info readers call record_line to add each source > location / pc mapping they find to GDB's internal tables. The issue > at hand is that record_line currently calls gdbarch_addr_bits_remove > on the pc values it's passed before recording them; apparently some > debug info had extra bits set in the addresses in the line number > info. Since this doesn't meet the spec (of either DWARF or STABS), > it's a bug in the producer; the call to gdbarch_addr_bits_remove is > meant to work around that bug. We've been discussing removing that > call, since it has caused problems recently. I think the comment is likely wrong. I can see using the bits in dwarf or stabs information might cause problems. Hopefully, this isn't the case (ie., binutils doesn't need fixing). It is possible the bits need masking from the relocated unwind or the HP debug info in the $DEBUG$ space. The best source of information for HP debug info is the HP-UX 10.20 run-time architecure document. I believe this information was dropped from the public HP-UX 11 document. The bits do arise whenever the program counter is saved on the stack or copied to a register. In that case, the bits need to masked. This probably should be done arlier. Priority can occur on calls. This normally only used for system calls. There is no support priority changes in GCC. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602)