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: [M32C] : No error is reported when relocation gets overflowed.


> However, using binutils dated 20070417, I do not get any linker error.

Note that the linker will normally create a PLT entry for references
outside of the first 64k, with the assumption that you're taking the
address of a function.  These PLTs go in .rodata, so putting .rodata
outside of the first 64k will break things.

Also, since all 16 bit accesses that are outside the first 64k are
turned into PLTs, such relocs can't really overflow.

I think the only way to solve this cleanly is to either (1) add a new
type of reloc for 16-bit accesses to functions (however, even gcc
doesn't always know when a pointer is going to be used for a function
call and when it's going to be used for something else), or have the
linker disassemble each opcode that's using 16 bit relocs to check for
using the reloc as an address or as an aimmediate (which it can't do
at all unless it's relaxing, and even then it's impossible to know for
sure what an address is going to be used for).

Unless someone comes up with a clever solution that isn't too painful
to implement, I think we're going to have to just live with it and not
do nonsensical things like putting .rodata outside of our data space.
(if you're trying to implement far pointers, the solution is to use a
specific section, like .fdata, and have gcc tag all the things that it
*knows* are out there, and address them accordingly).


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