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


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


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