back into the thread....

back into the thread....

[Mark Manning]

Got a reply from someone here about my problems with gdb but i cannot
figure out how to reply all and googles reply always top posts my
replies.  Also i still have the same issue in that i cannot execute
code that is not part of the original executables object.  any
additional code written into memory by my compiler is not executable
yet the person who replied to me said that it SHOULD be possible as he
does it all the time.

this is a version of gdb running on an arm target (beagle board xm)
under a gentoo linux install - is this a bug injected into gdb by some
gentoo snafu?


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

-- Enrique Jardiel Poncela --

Re: back into the thread....

[Sterling Augustine]

This feature clearly works.

On Tue, Nov 12, 2013 at 2:08 PM, Mark Manning <mark4th@gmail.com> wrote:
> Got a reply from someone here about my problems with gdb but i cannot
> figure out how to reply all and googles reply always top posts my
> replies.  Also i still have the same issue in that i cannot execute
> code that is not part of the original executables object.  any
> additional code written into memory by my compiler is not executable
> yet the person who replied to me said that it SHOULD be possible as he
> does it all the time.
>
> this is a version of gdb running on an arm target (beagle board xm)
> under a gentoo linux install - is this a bug injected into gdb by some
> gentoo snafu?

If gdb doesn't think the memory is accessible, then it probably isn't.

The following test-case works perfectly well for gdb. You may want to
be sure that you are following all the correct steps in your code
generator, particularly the posix_memalign and mprotect. Otherwise
your code will take an unexpected segfault. I can set a breakpoint at
dst and stepi through it no problem.

The contents of bytes comes from compiling

int foo(int x) { return x; }

at O2 and then copying the resulting bytes into the array. You would
want to do something similar to get ARM results. Be sure it doesn't
have relocations.

=====

#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <string.h>
#include <malloc.h>

const char bytes[] = { 0x89, 0xf8, 0xc3 };
#define EXEC_BYTES sizeof(bytes)

typedef int(*function_ptr)(int);

int main(int argc, char *argv[])
{
  int test_val;
  int return_val;
  function_ptr dst = malloc(EXEC_BYTES);
  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);
  }

  if (argc > 1)
    test_val = atoi(argv[1]);

  memcpy(dst, bytes, EXEC_BYTES);

  return_val = dst(test_val);
  printf("return val was %d\n", return_val);
  return 0;

}

Re: back into the thread....

[Sterling Augustine]

On Tue, Nov 12, 2013 at 2:42 PM, Sterling Augustine
<saugustine@google.com> wrote:
> This feature clearly works.
>

.. This time with a couple of cleanups. The old example definitely
works, this just eliminates an extraneous call to malloc and an
uninitialized variable.

include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <string.h>
#include <malloc.h>

const char bytes[] = { 0x89, 0xf8, 0xc3 };
#define EXEC_BYTES sizeof(bytes)

typedef int(*function_ptr)(int);

int main(int argc, char *argv[])
{
  int test_val = 5;
  int return_val;
  function_ptr dst;
  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);
  }

  if (argc > 1)
    test_val = atoi(argv[1]);

  memcpy(dst, bytes, EXEC_BYTES);

  return_val = dst(test_val);
  printf("return val was %d\n", return_val);
  return 0;
}

Re: back into the thread....

[Mark Manning]

tried to compile your code but all i get is about 400 errors related
to error unknown type name 'size_t' from stdlib.h.




On Tue, Nov 12, 2013 at 5:47 PM, Sterling Augustine
<saugustine@google.com> wrote:
> On Tue, Nov 12, 2013 at 2:42 PM, Sterling Augustine
> <saugustine@google.com> wrote:
>> This feature clearly works.
>>
>
> .. This time with a couple of cleanups. The old example definitely
> works, this just eliminates an extraneous call to malloc and an
> uninitialized variable.
>
> include <stdio.h>
> #include <stdlib.h>
> #include <sys/mman.h>
> #include <string.h>
> #include <malloc.h>
>
> const char bytes[] = { 0x89, 0xf8, 0xc3 };
> #define EXEC_BYTES sizeof(bytes)
>
> typedef int(*function_ptr)(int);
>
> int main(int argc, char *argv[])
> {
>   int test_val = 5;
>   int return_val;
>   function_ptr dst;
>   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);
>   }
>
>   if (argc > 1)
>     test_val = atoi(argv[1]);
>
>   memcpy(dst, bytes, EXEC_BYTES);
>
>   return_val = dst(test_val);
>   printf("return val was %d\n", return_val);
>   return 0;
> }



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

-- Enrique Jardiel Poncela --

Re: back into the thread....

[Mark Manning]

disregard, you pasted in the new copy but missed the initial # on the
first include. i also missed that :)

On Tue, Nov 12, 2013 at 5:59 PM, Mark Manning <mark4th@gmail.com> wrote:
> tried to compile your code but all i get is about 400 errors related
> to error unknown type name 'size_t' from stdlib.h.
>
>
>
>
> On Tue, Nov 12, 2013 at 5:47 PM, Sterling Augustine
> <saugustine@google.com> wrote:
>> On Tue, Nov 12, 2013 at 2:42 PM, Sterling Augustine
>> <saugustine@google.com> wrote:
>>> This feature clearly works.
>>>
>>
>> .. This time with a couple of cleanups. The old example definitely
>> works, this just eliminates an extraneous call to malloc and an
>> uninitialized variable.
>>
>> include <stdio.h>
>> #include <stdlib.h>
>> #include <sys/mman.h>
>> #include <string.h>
>> #include <malloc.h>
>>
>> const char bytes[] = { 0x89, 0xf8, 0xc3 };
>> #define EXEC_BYTES sizeof(bytes)
>>
>> typedef int(*function_ptr)(int);
>>
>> int main(int argc, char *argv[])
>> {
>>   int test_val = 5;
>>   int return_val;
>>   function_ptr dst;
>>   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);
>>   }
>>
>>   if (argc > 1)
>>     test_val = atoi(argv[1]);
>>
>>   memcpy(dst, bytes, EXEC_BYTES);
>>
>>   return_val = dst(test_val);
>>   printf("return val was %d\n", return_val);
>>   return 0;
>> }
>
>
>
> --
> "When something can be read without effort,
> great effort has gone into its writing."
>
> -- Enrique Jardiel Poncela --



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

-- Enrique Jardiel Poncela --

Re: back into the thread....

[Sterling Augustine]

On Tue, Nov 12, 2013 at 3:04 PM, Mark Manning <mark4th@gmail.com> wrote:
> Built your example code, single stepped opcodes and executed the call
> to the poked in function.  the instant you execute the BL opcode into
> this function you get "Cannot access memory at address 0"

Please stop trimming the gdb list.

Does it run successfully without gdb at all? If it doesn't, then the
problem is somewhere in the system you are using.

If it does, then there is a bug in gdb here. File a bug either on
sourceware.org or with whomever supports your installation. As this is
likely very platform specific, you are likely to get better help from
your own support group.

Not much more we can do.

Re: back into the thread....

[Mark Manning]

actually i lied. i get
"Cannot access memory at address 8" in this case

On Tue, Nov 12, 2013 at 5:47 PM, Sterling Augustine
<saugustine@google.com> wrote:
> On Tue, Nov 12, 2013 at 2:42 PM, Sterling Augustine
> <saugustine@google.com> wrote:
>> This feature clearly works.
>>
>
> .. This time with a couple of cleanups. The old example definitely
> works, this just eliminates an extraneous call to malloc and an
> uninitialized variable.
>
> include <stdio.h>
> #include <stdlib.h>
> #include <sys/mman.h>
> #include <string.h>
> #include <malloc.h>
>
> const char bytes[] = { 0x89, 0xf8, 0xc3 };
> #define EXEC_BYTES sizeof(bytes)
>
> typedef int(*function_ptr)(int);
>
> int main(int argc, char *argv[])
> {
>   int test_val = 5;
>   int return_val;
>   function_ptr dst;
>   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);
>   }
>
>   if (argc > 1)
>     test_val = atoi(argv[1]);
>
>   memcpy(dst, bytes, EXEC_BYTES);
>
>   return_val = dst(test_val);
>   printf("return val was %d\n", return_val);
>   return 0;
> }



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

-- Enrique Jardiel Poncela --

Re: back into the thread....

[Phi Debian]

Hi All,

Off topic about gdb discution

>  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 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'

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


Cheers,
Phi

Re: back into the thread....

[Mark Manning]

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 --

Re: back into the thread....

[Phi Debian]

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

Re: back into the thread....

[Mark Manning]

On Wed, Nov 13, 2013 at 7:53 AM, Phi Debian <phi.debian@gmail.com> wrote:
> 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

im 90% certain the icache has been cleared...

  push r0                   @ point r0 at where new word starts in code
  ldr r2, =old_dp
  ldr r0, [r2, #BODY]       @ point where new word ends in code
  ldr r1, =dp
  ldr r1, [r1, #BODY]
  str r1, [r2, #BODY]       @ new end = next start

  movw r7, #2               @ clear icache for selected range
  movt r7, #15
  mov r2, #0
  swi 0
  ...

btw, "dp" in forth is a variable called the dictionary pointer, this
points to the memory where your next piece of compiled code will be
stored. after compiling something the code compiled will lie between
old dp and current dp - the above snippet theoretically clears the
icache between those two memory ranges.


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

-- Enrique Jardiel Poncela --

RE: back into the thread....

[Arnab Bhaduri]

Perhaps gdb's attempt to inspect the stack is what is causing the "address 0" problem ? I would do this:

- immediately before stepping the "mov pc, r1" instruction, do "set debug remote 1".
- this will produce a verbose log of gdb's interaction with the target.
- post the log to this thread.

Arnab

> -----Original Message-----
> From: Mark Manning [mailto:mark4th@gmail.com]
> Sent: Wednesday, November 13, 2013 4:59 AM
> To: Phi Debian
> Cc: Sterling Augustine; gdb@sourceware.org
> Subject: Re: back into the thread....
> 
> On Wed, Nov 13, 2013 at 7:53 AM, Phi Debian <phi.debian@gmail.com>
> wrote:
> > 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
> 
> im 90% certain the icache has been cleared...
> 
>   push r0                   @ point r0 at where new word starts in code
>   ldr r2, =old_dp
>   ldr r0, [r2, #BODY]       @ point where new word ends in code
>   ldr r1, =dp
>   ldr r1, [r1, #BODY]
>   str r1, [r2, #BODY]       @ new end = next start
> 
>   movw r7, #2               @ clear icache for selected range
>   movt r7, #15
>   mov r2, #0
>   swi 0
>   ...
> 
> btw, "dp" in forth is a variable called the dictionary pointer, this
> points to the memory where your next piece of compiled code will be
> stored. after compiling something the code compiled will lie between old
> dp and current dp - the above snippet theoretically clears the icache
> between those two memory ranges.
> 
> 
> --
> "When something can be read without effort, great effort has gone into
> its writing."
> 
> -- Enrique Jardiel Poncela --

Re: back into the thread....

[Mark Manning]

This will probably be top posted, no way to NOT top post with gmail
that i can  see but anyway.

My process on load calls an mprotect on its entire 1 meg of space to
change that entire memory range to +rwx so not being executable is not
the problem.  The code is also always aligned properly, this is not
the nature of my bug.

Also, the "can not access addres zero" error is totally bogus, there
is no attempted access to address zero by my code.  What i believe is
happening is GDB is accessing some structure related to debug info for
the code it is about to execute and the pointer it is trying to use is
null (this is pure guesswork).

The exact address that is in question here is 0xc000 which due to my
ye-olde C64 days is very easy to remember :).  After hitting my break
point i jump to this address, i know the program counter is at this
address because i can do a dump of the disassembly from $pc but
someone somewhere is attempting to access address zero immediately
after i single step that branch (actally a mov pc, lr).

I will attempt to run your supplied code and see what results i get



On Tue, Nov 12, 2013 at 5:42 PM, Sterling Augustine
<saugustine@google.com> wrote:
> This feature clearly works.
>
> On Tue, Nov 12, 2013 at 2:08 PM, Mark Manning <mark4th@gmail.com> wrote:
>> Got a reply from someone here about my problems with gdb but i cannot
>> figure out how to reply all and googles reply always top posts my
>> replies.  Also i still have the same issue in that i cannot execute
>> code that is not part of the original executables object.  any
>> additional code written into memory by my compiler is not executable
>> yet the person who replied to me said that it SHOULD be possible as he
>> does it all the time.
>>
>> this is a version of gdb running on an arm target (beagle board xm)
>> under a gentoo linux install - is this a bug injected into gdb by some
>> gentoo snafu?
>
> If gdb doesn't think the memory is accessible, then it probably isn't.
>
> The following test-case works perfectly well for gdb. You may want to
> be sure that you are following all the correct steps in your code
> generator, particularly the posix_memalign and mprotect. Otherwise
> your code will take an unexpected segfault. I can set a breakpoint at
> dst and stepi through it no problem.
>
> The contents of bytes comes from compiling
>
> int foo(int x) { return x; }
>
> at O2 and then copying the resulting bytes into the array. You would
> want to do something similar to get ARM results. Be sure it doesn't
> have relocations.
>
> =====
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <sys/mman.h>
> #include <string.h>
> #include <malloc.h>
>
> const char bytes[] = { 0x89, 0xf8, 0xc3 };
> #define EXEC_BYTES sizeof(bytes)
>
> typedef int(*function_ptr)(int);
>
> int main(int argc, char *argv[])
> {
>   int test_val;
>   int return_val;
>   function_ptr dst = malloc(EXEC_BYTES);
>   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);
>   }
>
>   if (argc > 1)
>     test_val = atoi(argv[1]);
>
>   memcpy(dst, bytes, EXEC_BYTES);
>
>   return_val = dst(test_val);
>   printf("return val was %d\n", return_val);
>   return 0;
>
> }



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

-- Enrique Jardiel Poncela --

Re: back into the thread....

[Pedro Alves]

On 11/12/2013 10:54 PM, Mark Manning wrote:
> 
> Also, the "can not access addres zero" error is totally bogus, there
> is no attempted access to address zero by my code.  What i believe is
> happening is GDB is accessing some structure related to debug info for
> the code it is about to execute and the pointer it is trying to use is
> null (this is pure guesswork).
> 
> The exact address that is in question here is 0xc000 which due to my
> ye-olde C64 days is very easy to remember :).  After hitting my break
> point i jump to this address, i know the program counter is at this
> address because i can do a dump of the disassembly from $pc but
> someone somewhere is attempting to access address zero immediately
> after i single step that branch (actally a mov pc, lr).

"mov pc, lr" moves the contents of $lr to $pc.  IOW, it's a jump.
ARM has no hardware single-step support.  This means that to single-step
one instruction, GDB has to figure out where the instruction might
land (by disassembling the instruction and being aware of the instruction
set), place a breakpoint there, and then let execution continue.

It just sounds like $lr is 0, and GDB is then trying to set
the breakpoint there, which of course fails.  That would be a
bug in your code, not GDB.

-- 
Pedro Alves