From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32034 invoked by alias); 14 Oct 2011 07:54:21 -0000 Received: (qmail 31916 invoked by uid 22791); 14 Oct 2011 07:54:15 -0000 X-SWARE-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,BAYES_00,TW_GB X-Spam-Check-By: sourceware.org Received: from eu1sys200aog105.obsmtp.com (HELO eu1sys200aog105.obsmtp.com) (207.126.144.119) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 14 Oct 2011 07:53:59 +0000 Received: from beta.dmz-eu.st.com ([164.129.1.35]) (using TLSv1) by eu1sys200aob105.postini.com ([207.126.147.11]) with SMTP; Fri, 14 Oct 2011 07:53:59 UTC Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 96E9F1C7; Fri, 14 Oct 2011 07:53:43 +0000 (GMT) Received: from Webmail-eu.st.com (safex1hubcas4.st.com [10.75.90.69]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 3D5641706; Fri, 14 Oct 2011 07:53:43 +0000 (GMT) Received: from SAFEX1MAIL4.st.com ([10.75.90.10]) by Safex1hubcas4.st.com ([10.75.90.69]) with mapi; Fri, 14 Oct 2011 09:53:42 +0200 From: Marc TITINGER To: Kevin Pouget , "gdb@sources.redhat.com" Cc: MikeW Date: Fri, 14 Oct 2011 07:54:00 -0000 Subject: RE: Can gdb handle aliased memory regions ? Message-ID: <5A300A8A9D10DF4EBD1BE0537D30AA9DB77C04FB98@SAFEX1MAIL4.st.com> References: In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: 2011-10/txt/msg00110.txt.bz2 Hi Mike, > -----Original Message----- > From: Kevin Pouget [mailto:kevin.pouget@gmail.com] > Sent: Thursday, October 13, 2011 6:16 PM > To: gdb@sources.redhat.com > Cc: MikeW; Marc TITINGER > Subject: Re: Can gdb handle aliased memory regions ? >=20 > On Wed, Oct 12, 2011 at 5:35 PM, MikeW wrote: > > Target platform: STLinux / ST Micro Connect > > > > On the target CPU, there is one region of physical memory that is > accessible by > > two different mapped memory address regions: one as cached memory and > one as > > uncached, eg. > > =A00x8000000 (virt cached) =A0 -> 0x40000000 (phys) > > =A00xDF00000 (virt uncached) -> 0x40000000 (phys) Is it 0xDF00000 or 0xDF00_0000 like below in this text ? I'm asking because= in the first case it looks like a VM (usermode) to Phy translation issue (= I'm assuming it is a Linux kernel), while below, it looks like a kernel to = physical memory mapping question ?=20 > > > > During the kernel init, there is a code sequence which switches > between cached > > and uncached (to update cache registers etc) and expects the > execution to > > proceed from eg. 0x80001234 to 0xDF001236. So IIUC, you are running kernel code and at that point you which to tell th= e debugger to use a different offset and resume. Maybe the kernel has a mem= info.bank dedicated to the uncached mapping that we could use. > > > > Stepping with gdb is fine until the switchover point is reached, > > whereupon gdb thinks it's lost control ('step[i]', 'next' or 'finish' > > do not return to the (gdb) prompt), but of course the ms bits of > > the PC just refer to the other region. > > > > I note gbd has support for the older technique of overlays; is there > any way to > > tell gdb that the 0x8000... and 0xDF00... regions are actually the > same physical > > memory ? AFAIK the linux-awareness target does not support this currently unfortunat= ely, but it would be easy to add a command to switch the memory bank from t= he tty at that point.=20 May I ask you to send me the type of SoC, stlinux and gdb versions you are = using ? Many thanks, Marc.=20 =20 > > > > Thanks. >=20 > stlinux kernel debugger maintainer cc'd