Jamie Lokier wrote:
Gavin Lambert wrote:
Quoth Jamie Lokier:
But this part of the kernel will relocate incorrectly in border
cases with XIP:
if (r < text_len) /* In text segment */
addr = r + start_code;
else /* In data segment */
addr = r - text_len + start_data;
If there's an object in the (writable) data section, and the code (or
data) needs a reloc pointing to negative offset relative to it, the
kernel will point the reloc to the text section, when it should be a
negative offset relative to the data section. In XIP, these values
are different, and that means an address, either in the code or in
some initialised data, will be wrong after relocating. Similarly with
relocs pointing to positive offsets outside objects in code or
read-only data.
Shouldn't the relocations themselves specify whether they're code or data
relocations then?
Yes, this would fix them. Note, it doesn't matter whether they are
relocs _in_ code or data which matters. (That's what "code or data
relocs" would often mean). What matters is which section the address
the relocated word points to.
These things are fine with ELF binaries, as ELF relocs encode which
section they are relative to. They are also fine when the different
sections cannot be relocated independently. Probably the compiler has
optimisations which do that, assuming it's ok, but it's not in those
corner cases with bFLT-XIP.
Would it be possible to change the bFLT format to include this sort of
information as well?
Definitely. It wouldn't be compatible with the existing bFLT format,
but you could make it backward compatible so those relocs which are
currently fine could stay the same. That would be quite an ugly
workaround though.
bFLT version 5 seems to do it right (used on MIPS and Blackfin). Look
at the calc_v5_reloc function in binfmt_flat.c. Perhaps that should
be extended to the other architectures. The ELF loaders are a good
place to discover which reloc types are needed by each architecture.
I don't know if that would make the binaries larger.
Or just ditch bFLT and make FDPIC work on all the architectures, that
would be nice :-)
A much better solution :-)
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
Secure Computing Corporation PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
