incorrect dereference of implicit memcpy

[Woytech Karl-Heinz]

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?

Andrew Haley:

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

Thanks for the prompt answer and the food for though,

I would like to leave my sticky little fingers from patching gcc at the
moment as this would restict all our developers to one specially
compiled gcc.

Currently we are considering either adding the following to the
application code
__asm__
  (".bss                  \n"
   ".align 4              \n"
   "dmymemcpy : .space 3  \n"
   ".globl memcpy         \n"
   "memcpy    : .space 1  \n"
   ".globl fmemcpy        \n"
   "fmemcpy   : .space 4  \n");
extern char memcpy;
extern memcpy_t fmemcpy; 
memcpy = 0xe9; // jmp [abs]
#define memcpy(d,s,l) fmemcpy((d),(s),(l))

which would not break our legacy function ptr code and keeps gcc happy 
or just statically linking a memcpy to the applications (even easier)

kind regards
 charlie