This is the mail archive of the binutils@sourceware.org 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]

Re: wanted: relocation for each field of instruction


John Reiser <jreiser@BitWagon.com> writes:

> I'm looking for the ability to relocate each field of an instruction,
> particularly any field which holds an immediate value.  My compiler
> generates machine-code schemas where the opcodes are fixed, but the
> immediate values (shift amounts, offsets, etc.) are variable.
> I seek the ability to re-assign these "absolute" quantities
> at module binding time (/bin/ld).
>
> For instance in Thumb mode on ARM:
> 	.code 16
> 	lsr r0,r1,#foo    /* 5-bit immediate shift count */
> 	add r3,r2,#bar    /* 3-bit immediate increment */
> 	ldr r3,[r4,#baz]  /* 8-bit base offset */
> Current assembler complains:
>    reloc.S:2: Error: cannot represent THUMB_SHIFT relocation in this object file format
>    reloc.S:3: Error: cannot represent THUMB_ADD relocation in this object file format
>    reloc.S:4: Error: cannot represent THUMB_OFFSET relocation in this object file format
>
> In the future my schemas might expand to allow register numbers to be
> re-assigned too.  This would enable cross-procedure optimization by
> re-writing calling sequences to use a different register assignment.
>
> It seems to me that making THUMB_SHIFT, THUMB_ADD, and THUMB_OFFSET
> visible and known to the linker would be one way to get what I want.
> Comments?

As you know, ELF defines relocation codes to implement specific
operations.  The operations are picked based on what a typical assembler
and linker will require to find functions and variables.  Other object
file formats do things differently, and in particular IEEE-695 supports
using arbitrary expressions when computing relocations.  The
disadvantage of the IEEE-695 approach is that it makes the linker
slower.  This is particularly a concern for the dynamic linker.

Anyhow, given ELF, there are two possible approaches.  One is the one
you mention: define a set of new relocations, like THUMB_SHIFT, enough
to let you do whatever you need.  The other is to define a set of
relocations which permit arbitrary expression evaluation.  For example,
Alpha ECOFF implemented a limited form of this.

* ALPHA_R_OP_PUSH pushes the addend on the relocation stack.
* ALPHA_R_OP_STORE stores the top of the stack into the instruction at
  the reloc address; the addend defines the bitfield where the
  instruction is stored.  This is also pops the stack.
* ALPHA_R_OP_PSUB subtracts the addend from the top of the stack.
* ALPHA_R_OP_PRSHIFT shifts the top of the stack right by the addend.

The advantage of using THUMB_SHIFT is that the expressions are known,
and your optimizers can know exactly how the values are being used.  The
advantage of using general expressions is that you can express whatever
you like.

Ian


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