From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17139 invoked by alias); 24 Oct 2007 19:46:59 -0000 Received: (qmail 17128 invoked by uid 22791); 24 Oct 2007 19:46:58 -0000 X-Spam-Check-By: sourceware.org Received: from waste.org (HELO waste.org) (66.93.16.53) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 24 Oct 2007 19:46:54 +0000 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.8/8.13.8/Debian-3) with ESMTP id l9OJkfti010249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Oct 2007 14:46:41 -0500 Received: (from oxymoron@localhost) by waste.org (8.13.8/8.13.8/Submit) id l9OJkeYw010247; Wed, 24 Oct 2007 14:46:40 -0500 Date: Wed, 24 Oct 2007 19:46:00 -0000 From: Matt Mackall To: linuxppc-embedded@ozlabs.org Cc: gdb@sourceware.org Subject: Apparent kernel bug with GDB on ppc405 Message-ID: <20071024194640.GB19691@waste.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) 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/msg00204.txt.bz2 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(). Adding printk(".") (or any printk) in this function here fixes things (serial console at 115k), while printk("") and udelay(100) do not. Which still suggests an icache bug..? Any suggestions? -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."