* Porting to a target similar to an existing one
@ 2004-04-30 10:45 Bernd Jendrissek
2004-05-05 16:15 ` Nick Clifton
0 siblings, 1 reply; 2+ messages in thread
From: Bernd Jendrissek @ 2004-04-30 10:45 UTC (permalink / raw)
To: binutils
-----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-----
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Porting to a target similar to an existing one
2004-04-30 10:45 Porting to a target similar to an existing one Bernd Jendrissek
@ 2004-05-05 16:15 ` Nick Clifton
0 siblings, 0 replies; 2+ messages in thread
From: Nick Clifton @ 2004-05-05 16:15 UTC (permalink / raw)
To: Bernd Jendrissek; +Cc: binutils
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2004-05-05 16:15 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-04-30 10:45 Porting to a target similar to an existing one Bernd Jendrissek
2004-05-05 16:15 ` Nick Clifton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).