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: 16-bit relocations in 32-bit code


On 03/15/2010 03:43 PM, Andrew Zabolotny wrote:
>> However, given the existance of R_386_PC16, you should be able to
>> represent ".short SYM-." for any SYM on both i386 and x86_64.
> I don't quite get the idea. ".short SYM-." won't generate any
> relocation at all, how this can help me?

Certainly it does.  Didn't you even try it?

[anchor:~] cat z.s
	.short	SYM-.
[anchor:~] as -32 -o z.o z.s
[anchor:~] readelf -r z.o

Relocation section '.rel.text' at offset 0x200 contains 1 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000000  00000415 R_386_PC16        00000000   SYM

It won't generate a relocation if SYM is defined in the same file,
but that's ok, because the assembler has already filled in the 
correct result.

> Some platforms support the modificator lo16(addr). This is the ideal
> solution for my problem; unfortunately, i386 does not support it.

It isn't, actually.  This is usually a field inside a 32-bit instruction
and not a bare 16-bit quantity.  It also is to be paired with a hi(addr)
relocation, and so absolutely no error checking is performed if the lo16
is out of range.

>> For portability to other machines, you might consider writing
>> your own trivial assembler and linker for the forth.  You
>> can then include the linked forth program into the native 
>> binary via .incbin or the like.
> That's what I'm trying to avoid by using binutils as the swiss army
> knife :)

Ouch.  ;-)


r~


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