Porting to a target similar to an existing one

Porting to a target similar to an existing one

[Bernd Jendrissek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all

I'm hunting down some problem with a VeriFone SC 5000 pinpad, which
happens to use a v850 processor.  So both GCC and binutils support the
instruction set.

Problem: the development libraries are supplied by Green Hills, who use
a different output file format than elf32-v850.  It's still ELF, but it
has e_machine = EM_V800 (0x36) instead of EM_V850.

After being flummoxed for a while that the (GNU) linker segfaulted when
I tried to link my object files with their libraries, I realised that
their ELF used different relocations than the GNU elf32-v850!

So now I've just copied most of the v850 stuff into new files named
*-v850.*, and started hacking away.  But before I get too far, I guess I
should ask:

What do you guys recommend?  Should I just go for a brand new target,
effectively forking the v850 code, or should I litter the v850 code with
flags and ifdefs and other uglification?  The different relocation
flavour seems to suggest quite a deep schism...

Any ideas?

Oh, and BTW, is there anywhere I can lookup what the relocations are
supposed to do, besides guessing based on their name?  (They have a
utility "gdump" which lists the relocations by name.)

- -- 
http://voyager.abite.co.za/~berndj/ (up again for now - yay!)
"IBM has more patent litigation lawyers than SCO has employees." - unknown
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAkiyZ/FmLrNfLpjMRAsutAJ4hn9Bagw2w6lqeE9+Z0Mi5aP35NACeO4a7
YNiKN0wHaQlRRCeuCnAvV78=
=bTOA
-----END PGP SIGNATURE-----

Re: Porting to a target similar to an existing one

[Nick Clifton]

Hi Bernd,

  [Sorry for the delay in replying to this email].

>What do you guys recommend?  Should I just go for a brand new target,
>effectively forking the v850 code, or should I litter the v850 code with
>flags and ifdefs and other uglification?  The different relocation
>flavour seems to suggest quite a deep schism...
>  
>
I would suggest a new target with a new manufacturer field (the middle 
field). eg something like this:

    --target=v850-greenhills-elf

I would also suggest that you arrange for v850-elf and v850-gnu-elf to 
be aliases for v850-unknown-elf.
 
Note - if you find that there is lots of common code between the "Green 
Hills" target and the GNU one, there is no reason why you should not 
extract this code into a shared file.

>Oh, and BTW, is there anywhere I can lookup what the relocations are
>supposed to do, besides guessing based on their name?  
>

The meaning of the relocations really ought to be defined by the EABI in 
use.  Therefore you should check the Green Hills documentation to see 
what EABI they follow and attempt to find the documentation on that.  It 
may well be that there is no properly defined EABI, which is why there 
are differences between the Green Hills and GNU compilers.  You can 
always check the source code for the implementation of the GNU versions 
of the relocs, but I doubt if Green Hills will be willing to let you 
look at their code...

Cheers
  Nick