From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15508 invoked by alias); 21 Dec 2005 11:04:33 -0000 Received: (qmail 15500 invoked by uid 22791); 21 Dec 2005 11:04:33 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.196) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 21 Dec 2005 11:04:32 +0000 Received: by zproxy.gmail.com with SMTP id l1so134375nzf for ; Wed, 21 Dec 2005 03:04:30 -0800 (PST) Received: by 10.36.146.1 with SMTP id t1mr550948nzd; Wed, 21 Dec 2005 03:04:30 -0800 (PST) Received: by 10.37.2.6 with HTTP; Wed, 21 Dec 2005 03:04:30 -0800 (PST) Message-ID: <8f2776cb0512210304s55c7181am8a6e2d711c943ed2@mail.gmail.com> Date: Wed, 21 Dec 2005 11:04:00 -0000 From: Jim Blandy To: Shrirang Khishti Subject: Re: regarding problem in porting gdb Cc: gdb@sources.redhat.com In-Reply-To: <4A1BE23A7B777442B60F4B4916AE0F13094BF11E@sohm.kpit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4A1BE23A7B777442B60F4B4916AE0F13094BF11E@sohm.kpit.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00170.txt.bz2 On 12/21/05, Shrirang Khishti wrote: > Hi Jim > Thanks for your help and changes suggested by you. But in our > target GCC we have added a different memory model which handles 32 bits > of address size and for that we are not getting any problem. But for > the memory model for which I am facing the problem we don't need 32 > bits address size(For this model code size is limited to 64K but > situated at some far address). So in this case it is as good as debug > info is showing virtual addresses related to program counter If your PC is only 16 bits long, and the upper bits are provided by some other register, but the addresses GDB uses to access the target address space index the larger address space, you may need to define a gdbarch_read_pc method, and have your 'struct frame_unwind' include a prev_pc function, to ensure that those upper bits get added as appropriate.