Re: back into the thread....

[Mark Manning <mark4th@gmail.com>]

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.

>>  if (posix_memalign((void **) &dst, 4096*8, EXEC_BYTES) != 0) {
>>   printf("can't allocate.\n");
>>  exit (-1);
>>  }
>>  if (mprotect(dst, EXEC_BYTES, PROT_READ|PROT_WRITE|PROT_EXEC) != 0) {
>>    printf("can't mprotect\n");
>>    exit (-1);
>>  }
>
>>   memcpy(dst, bytes, EXEC_BYTES);
>>
>>   return_val = dst(test_val);
>
>
> The above code as very little chance to execute on modernn
> architecture, at least with architecture with separate icache and
> dcache.

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.

>
> The memcpy fill the dcache, the dst() read the icache, since the
> caches are not flushed in between, the dst() will execute garbage
> (well instruction living there before).
>
> As far as GDB is concerned, it should be able to single step in any
> memory area that is declared 'executable'

the first thing i do with my ENTIRE one meg of process space is
mprotect it to +rwx.  this is not the problem i am experiencing
either.

>
>> Also, the "can not access addres zero" error is totally bogus,
> Not if you consider your single step execute garbage instruction.
>

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.

Single step one opcode again and the program counter DOES NOT
MOVE!!!!! and I still get the "cannot access address zero" plus an
error I couldn't remember when I posted this thread initially about
gdb not knowing where the current function starts or ends.

There is no further single stepping of any opcodes.  GDB refuses to
execute the opcode at $pc. PERIOD.

i do not know if this is a bug in all versions of gdb, it may be that
it is only present in the arm version of gdb and maybe only in the
gentoo arm version of gdb.  i have no idea, all i know is my debug
efforts are now totally dead ended until this is resolved and i have
no idea how to resolve it.


> Cheers,
> Phi



-- 
"When something can be read without effort,
great effort has gone into its writing."

-- Enrique Jardiel Poncela --