[EMAIL PROTECTED] wrote:
> > What does "BINFMT_FLAT: reloc outside program" mean, and how do I fix
> > it?
>
> It means pretty much what it says. A relocation is pointing out
> program text and data areas and the kernel is erroring out over it.
>
> The fix is to remove this test from the binfmt_flat loader, it is
> possible to have relocations that are outside program areas and the
> more recent compilers seem to be producing such more often than when
> I did this:
So basically you're saying C++ works fine, provided that simple test
is removed from the kernel, is that right? Perhaps not:
> e.g. something like this might cause the problem:
>
> int x[10];
> int *y = &x[-1000];
>
> No, this isn't legal C (at least according to the standard) but it
> works just about everywhere and the compiler is allowed to produce
> code equivalent to this if it wants.
If the compiler is doing the equivalent of that - offsets outside of
objects, that makes sense. Some useful optimisations can be done with
that. 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.
The program will do weird things, maybe crash, or maybe
something subtler.
If the compiler does that more often with C++, it would cause
occasional failures in C++ programs with XIP... But it could do it
with C programs too.
I wonder if it explains some of the other problems people had with C++
and PIC not working together?
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.
-- Jamie
_______________________________________________
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
