This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]