Re: [PATCH] add bfin target

["Michael Ambrus" <ambrmi09 at gmail dot com>]

Hi Alain and all,

Enclosed you will find a patch that you might find useful.

I wasn't able to figure out how you got the tool-chain for blackfin
build all the way from binutils to gdb for RTEMS. I figure you must
have trixed a lot with different configure settings for the various
parts (--target=bfin-rtems will not build even binutils ;( )

As an alternative I made this virtual system (HIXS) which *should*
work with most embedded targets. It's RTEMS inspired and it shares
some of RTEMS abilities. But I've made it simpler by *not* defining
more system calls than necessary (your application should do that
instead if needed).

When you compile HIXS you *don't* use HIXS as a system in the
canonical name. Instead you use it in the vendor part. This has the
advantage of the complete GNU tool-chain happily being able to compile
as long as the "true" system is supported. For embedded systems you
would for example use --target=arm-hixs-elf or --target=bfin-hixs-elf
for all the gnu tools and for newlib. ("True system" in this context
really only means choosing the calling convention).

HIXS also adds the ability to overload the system calls in run time,
which enables you to develop & debug your own target system more
easily. For each system call there is a corresponding hixs_ equivalent
function *pointer*, which by default points to a stubbed (but
"working") function. All you have to do is setting each hixs system
call to any of your own (preferably during start-up). See the example
below.

I've tested this with my ARM lpc2129 and it works fine. I haven't been
able to try it with bfin yet, since for some reason I get the ENDIAN
not being defined error while building GCC (first stage) all the time
now and I can't for the life of me figure out how I made it work last
time. Apparently GCC tries to figure out endianess by looking in the
newlib headers, but I think that might differ depending of which
version of GCC is used to compile the cross tool sources. If you have
time, I would much appreciate if you could add the endianess in
newlib-x.y.z/newlib/libc/include/ieeefp.h ;)

Below is a small example of how to use HIXS. Notice that additionally
to the hixs system calls, there is a system call monitor that will be
called in each stub. Overload this one first, and you can use it's
argument to figure out which system call was really executed.

Cheers
/Michael

...

//Declaring a helper variable to be used to figure out which stubbed
system call was
//executed. Declaring it as (any type of) function pointer
//enables gdb to look up it's name (practical when debugging).

void (*my_lastcall)(void);

void My_syscall_mon( void *syscall ) {
 my_lastcall = syscall;
}  //<- Set break-point here and inspect my_lastcall

int My_write(int file, char *ptr, int len){
  int todo;

 for (todo = 0; todo < len; todo++) {
    //writechar(*ptr++);
 }
 return len;
}

//We "know" the following functions exists. They are really function pointers
//so we need to let the compiler know they are assignable.
extern int  (*hixs_write)(int file, char *ptr, int len);
extern void (*hixs_syscall_mon)(void *syscall);

int main(int argc, char **argv){
 //Overload the _syscall_mon "sys-call" (by overloading it's hooked fuction)
 hixs_syscall_mon   = My_syscall_mon;

 //Now test your new syscall monitor
 hixs_syscall_mon(main); //Short-cut call
 _syscall_mon(main);       //Hooked call
 //If you return from here, monitoring *should* work

 //Overload the _write sys-call (by overloading it's hooked fuction)
 hixs_write=My_write;

 //The following call should now generate calls both to the syscall monitor
 //(i.e. My_syscall_mon since we overloaded it)  and to My_write
 printf("Hello world");

}

Attachment: newlib-hixs-060922.patch.gz
Description: GNU Zip compressed data