This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: back into the thread....


On Wed, Nov 13, 2013 at 1:29 PM, Mark Manning <mark4th@gmail.com> wrote:
> On Wed, Nov 13, 2013 at 1:48 AM, Phi Debian <phi.debian@gmail.com> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]