From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10723 invoked by alias); 12 Oct 2011 15:40:28 -0000 Received: (qmail 10562 invoked by uid 22791); 12 Oct 2011 15:40:25 -0000 X-SWARE-Spam-Status: No, hits=-0.3 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,RCVD_NUMERIC_HELO,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_GB,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 12 Oct 2011 15:40:09 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RE0ue-0005NA-Dw for gdb@sources.redhat.com; Wed, 12 Oct 2011 17:40:08 +0200 Received: from 94.72.250.67 ([94.72.250.67]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 12 Oct 2011 17:40:08 +0200 Received: from mw_phil by 94.72.250.67 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 12 Oct 2011 17:40:08 +0200 To: gdb@sources.redhat.com From: MikeW Subject: Can gdb handle aliased memory regions ? Date: Wed, 12 Oct 2011 15:40:00 -0000 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: Loom/3.14 (http://gmane.org/) X-IsSubscribed: yes 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/msg00072.txt.bz2 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. 0x8000000 (virt cached) -> 0x40000000 (phys) 0xDF00000 (virt uncached) -> 0x40000000 (phys) 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. 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 ? Thanks.