From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19599 invoked by alias); 13 Nov 2013 12:54:48 -0000 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 Received: (qmail 19588 invoked by uid 89); 13 Nov 2013 12:54:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RDNS_NONE,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-wi0-f182.google.com Received: from Unknown (HELO mail-wi0-f182.google.com) (209.85.212.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 13 Nov 2013 12:53:38 +0000 Received: by mail-wi0-f182.google.com with SMTP id i19so653650wiw.9 for ; Wed, 13 Nov 2013 04:53:29 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.11.38 with SMTP id n6mr32124496wjb.25.1384347209626; Wed, 13 Nov 2013 04:53:29 -0800 (PST) Received: by 10.216.167.200 with HTTP; Wed, 13 Nov 2013 04:53:29 -0800 (PST) In-Reply-To: References: Date: Wed, 13 Nov 2013 12:54:00 -0000 Message-ID: Subject: Re: back into the thread.... From: Phi Debian To: Mark Manning Cc: Sterling Augustine , gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00061.txt.bz2 On Wed, Nov 13, 2013 at 1:29 PM, Mark Manning wrote: > On Wed, Nov 13, 2013 at 1:48 AM, Phi Debian wrote: >> Hi All, >> >> Off topic about gdb discution >> > > Not off topic if it shows there is a bug in gdb which for the case of > embedded arm (maybe only in Gentoo?) i believe there is. I meant I was doing an off topic answer (not you your post was off topic. > the arm processor im running these things on does have an icache and i > know enough to clear it even if the person who gave me that code to > test forgot that minor detail. Not so minor ;) > > no. i stepi a "mov pc, r1" where r1 points to the new code. > immediately after single stepping this opcode im presented with the > error message about not being able to access address zero. > > I know the exact address that r1 was pointing to, it was 0xc000 (which > is very easy for a ye olde c64 coder to remember because it was the > region of memory at address 49152 that was placed between the kernel > and basic roms). > > Dump the disassembly of where the program counter points to and it > exactly what my compiler was supposed to lay down at address 0xc000. > There is no opcode misalignment. There are no bogus unimplemented > opcodes, the opcodes are exactly what should have been layed down by > the compiler given the sources that were fed to it. The program > counter also points to address 0xc000. Again seeing at 0xc000 what you would like to see doesn't mean that what you got in your icache. You could make your dynamic compiler generate few instruction into your buffer followed by a tight loop (while(1);) Then continue your execution instead of stepi, if whats in the icache is what you expect, then it will loop there and you can ^c to confirm, if you still got xyz gdb error message, you are not executing what you think you would Dynamic (self modifiable) code is tricky, look at emacs generated lisp, or at the kernel a.out loader code, they basically load buffer with data taht will later be executed.... Cheers, Phi