From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22948 invoked by alias); 24 Oct 2007 20:34:27 -0000 Received: (qmail 22938 invoked by uid 22791); 24 Oct 2007 20:34:26 -0000 X-Spam-Check-By: sourceware.org Received: from smtp1.dnsmadeeasy.com (HELO smtp1.dnsmadeeasy.com) (205.234.170.144) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 24 Oct 2007 20:34:21 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id 19B2530D8DE; Wed, 24 Oct 2007 20:34:34 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Wed, 24 Oct 2007 20:34:33 +0000 (UTC) Received: from [192.168.7.26] ([192.168.7.26]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 13:34:17 -0700 Message-ID: <471FAC48.1070008@avtrex.com> Date: Wed, 24 Oct 2007 20:34:00 -0000 From: David Daney User-Agent: Thunderbird 1.5.0.12 (X11/20070719) MIME-Version: 1.0 To: Matt Mackall Cc: linuxppc-embedded@ozlabs.org, gdb@sourceware.org Subject: Re: Apparent kernel bug with GDB on ppc405 References: <20071024194640.GB19691@waste.org> In-Reply-To: <20071024194640.GB19691@waste.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2007-10/txt/msg00208.txt.bz2 Matt Mackall wrote: > I'm trying to debug a trivial statically-linked hello world program on > a Xilinx PPC 405 and I'm seeing the following behavior: > > With direct gdb on target, I can set a breakpoint at main, run, and > the breakpoint is triggered. > > With gdbserver and gdb with "target remote localhost:1234", the above > still works. > > With gdb on target redirected to a PC and tunneled back > to the target, everything still works. > > With gdb on a PC, execution continues past the breakpoint. Comparing > the gdb protocol streams here and and on the previous (working) case > are identical up to the point of hitting the breakpoint (which never > happens in the latter case). > > Raising the load on the PC to 4 and running gdb under nice -n 19 makes > things work again. So this begins to look like a kernel cache or > timing bug rather than a problem with the PC tool. It appears that the > breakpoint written to the executable at continue time is not visible > to the CPU at execute time. > > My first suspicion was a dcache/icache coherency issue in > copy_to_user_page, so I added flush_dcache_icache_page(page) here to > no avail. On closer inspection, it looks like both icache and dcache > are already being flushed by flush_icache_user_range(). > First of all I have never used a similar configuration so this may be totally off base. But... If the icache is virtually indexed, then I think there are only two ways to invalidate it. The first is from the context of the debugged process where the page is mapped at the location the target program will see it. If you try to invalidate from the context of the debugger, the page will most likely not be mapped at the virtual address of the target program so you might have to invalidate the *entire* icache. David Daney