This is the mail archive of the
mailing list for the GDB project.
Re: back into the thread....
- From: Phi Debian <phi dot debian at gmail dot com>
- To: Mark Manning <mark4th at gmail dot com>
- Cc: Sterling Augustine <saugustine at google dot com>, gdb at sourceware dot org
- Date: Wed, 13 Nov 2013 13:53:29 +0100
- Subject: Re: back into the thread....
- Authentication-results: sourceware.org; auth=none
- References: <CAPGNrUX7TA-4eCrrP=sD9G6oNe5Kw=eWPm_jm-D7=9ZTz-v6BA at mail dot gmail dot com> <CAEG7qUx69s2cdp4XY3cGtAakDQAoSrGnbhgvvLxUzZG+rJKC_g at mail dot gmail dot com> <CAEG7qUyR8OZ=XGy0WwK=1UW46afS=e-67Hs=P3XToxKA1Q9+Pw at mail dot gmail dot com> <CAJOr74hUMywBACxchzpsL=+bur4s=iJaVQNdU0T0S4M2X15idw at mail dot gmail dot com> <CAPGNrUVd5ADBCQTJmHju+ZvWSGB-e8J-wjaUO2jF8XUnEZzXzw at mail dot gmail dot com>
On Wed, Nov 13, 2013 at 1:29 PM, Mark Manning <email@example.com> wrote:
> On Wed, Nov 13, 2013 at 1:48 AM, Phi Debian <firstname.lastname@example.org> 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....