Re: incorrect dereference of implicit memcpy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Woytech Karl-Heinz writes:

 > I am working on an x86 embedded system where we do not have ld/libc
 > onboard. our OS provides basic libc functions and does it's own dynamic
 > linking for the applications. 
 > 
 > Basic function dereferencing works properly, our problem is with the
 > implicit function calls that gcc makes for copying structs.
 > 
 > When the application code below gets started our OS finds the 'imex'
 > structure and correctly fills out the required function pointers so that
 > calls to the fn's result in the code provided by the os getting called.
 > 
 > Thus the explicit call
 >   jimbob(815);
 > translates to 
 >   push   $0x32f
 >   call   *0x804912c
 > 
 >   memcpy (dest, src, 20);
 > translates to 
 >   push   $0x14
 >   push   %ebx
 >   lea    0xffffff61(%ebp),%eax
 >   push   %eax
 >   call   *0x8049128
 > 
 > which is also good
 > BUT the structure copy x=y becomes
 >   push   $0x16
 >   push   %eax
 >   push   %edx
 >   call   8049128  <- no '*'
 > 
 > which is a direct jump into memory instead of a jump to the dereference
 > of the memory location. as of that moment the application crashes. below
 > are our build commands and the program.
 > 
 > Am I doing something wrong here, or do i have incorrect cflags/ldflags?
 > ie can i get gcc to produce the same derefecenced call as per the
 > explicit calls?

gcc generates a direct call to memcpy(), and it's up to you to make
sure that there is executable code at that address.  

However, given that you have the opportunity to change gcc's behaviour
by patching emit_block_move() to do something else, you can do so.
Also, you might like to look at init_block_move_fn().

I'm sure it would be a lot easier to put a jump instruction at memcpy,
though.

Andrew.

[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux