This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: TI COFFv2 relocations-- seen anything similar?
- From: "Charles Lepple" <clepple at ghz dot cc>
- To: <binutils at sources dot redhat dot com>
- Date: Thu, 15 Aug 2002 21:40:48 -0400 (EDT)
- Subject: Re: TI COFFv2 relocations-- seen anything similar?
my apologies for the last incomplete email-- although I have to place some
blame on the icky combination of Win2K and a webmail system that I'm using
since I'm at the office...
This was generated by a Perl script that I wrote to dump the relocation
table entries. The routine I ported from the existing TI COFF
infrastructure abort()ed after the first unrecognized reloc type (and
simply removing the abort call didn't work well).
_hundred_minus_bss:
00000160 C60_4013 0x00000064 (100) ;; literal operand
00000160 C60_4011 0x0000000e (14) ;; $bss
00000160 C60_4001 0x00000000 (0) ;; subtract
00000160 C60_4013 0x0000ffff (65535) ;; literal; mask for below
00000160 C60_4009 0x00000000 (0) ;; mask (and)
00000160 C60_400f 0x00201007 (2101255) ;; shift-and-mask
;; (bit pos 7, len 16)
This construct appears in a number of C programs which use near data
models, although not with this exact combination of operands. I have a
good number of the relocation types mapped out, but it's mostly guesswork.
The real problem is that all of the code in bfd/reloc.c is meant for
relocation entries that are applied without any saved state information.
These types of relocations essentially need a stack to processes the
arithmetic operations.
Is it safe to assume that all of the relocations would be processed in the
order they appear in the file? If that's the case, then I'd need some form
of static storage, which would make the code non-reentrant. (Is there an
approved private field in the relocation structures, or the main BFD
structure, that could be appropriated for this purpose?)
Since I'm effectively not working on the mainline binutils tree, it
shouldn't affect anyone right now if I were to add some saved-state
information to the relocation processing code (both reloc.c and the code
that calls it) but I'm trying to avoid collisions later on while merging.
thanks in advance,
--
Charles Lepple <clepple@ghz.cc>
http://www.ghz.cc/charles/