This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
TI COFFv2 relocations-- seen anything similar?
- From: Charles Lepple <clepple at ghz dot cc>
- To: binutils at sources dot redhat dot com
- Date: Wed, 7 Aug 2002 22:19:00 -0400
- Subject: TI COFFv2 relocations-- seen anything similar?
I'm working on porting the binutils to target TI's TMS320C6000 family of
DSPs, and I'm trying to avoid reinventing the wheel in the relocation
processing code.
So far, I have ported the tic54x* files to support similar constructs in
the 'C6x COFF files, but a number of object files generated by TI's C
compiler (and occasionally the assembly optimizer) have relocation table
entries with type codes greater than 0x4000.
Such entries appear in expressions such as this:
MVK .S1 (_c-$bss),A0
where the relationship between _c and $bss is not known at assembly time.
I'm still sorting through my notes, but I think that these relocation
types form a set of algebraic functions to enable the linker to calculate
crazy expressions such as "(_function1 - _main) >> 16 & 0xFFE0" at link
time.
TI's documentation is rather lacking in this area-- their COFF
specification appendix has incorrect structure member sizes, and doesn't
document any relocation codes greater than 0x4000.
I see that a great deal of effort has been put into making the relocation
system generic; however, it does not appear to handle arbitrary
expressions which have been bashed into the relocation table as such.
(The shifts and masks appear to be specified explicitly in the object file,
which would imply that TI's linker doesn't have to be updated to handle
new opcode encoding formats).
Anyway, does anyone know of another processor+file format combination
which handles things similarly? I am only vaguely familiar with ELF, and I
don't have enough background on the myriad of embedded processors (most of
which I don't recognize) in binutils these days.
Right now, all of the 'c6x source code is in CVS at SourceForge until such
time as it is moderately complete. (All my port really does is disassemble
a few of the simpler opcodes, and process the symbol table.) I'm open to
the idea of merging it into the binutils tree (probably on a branch for
now), but that's a topic for a new thread.
--
Charles Lepple <clepple@ghz.cc>
http://www.ghz.cc/charles/