Re: BINFMT_FLAT: reloc outside program

Hi Greg,
Greg Ungerer wrote,

> >You can find readelf, objdump -x, objdump -D and the source of
> >hello.c here:
> >http://debug.openadk.org/arm-pthreads/
> 
> If you compile supplying "-v" in the elf2flt flags then it
> will produce a verbose output that contains all the relocation
> information. That will be helpful here. (Post it here too if
> you want).

Attached is the log for this exec:
~ # ./hello 
BINFMT_FLAT: reloc outside program 0x99890000 (0 - 0x12588/0x8af0),
killing hello!
SEGV

Unfortunately I had to disable both ARM specific fprintf debug
outputs, as they generate a segfault in elf2flt again.
Are they required and helpful? Or should I send a patch to remove them?
 
> >Stracing the process does not work:
> >~ # ./strace ./hello
> >BINFMT_FLAT: Loading file: ./hello
> >./strace: Can't attach to 45: No such process
> >~ # Mapping is 70560000, Entry point is 45, data_start is 8b4c
> >Load ./hello: TEXT=70560040-70568b4c DATA=70568b50-7056e388
> >BSS=7056e388-705725e4
> >BINFMT_FLAT: reloc outside program 0xb5890000 (0 - 0x125a4/0x8b0c),
> >killing hello!
> 
> strace won't help you here. The program isn't running yet, the
> relocation failure is at exec time.

Okay, after using gdbserver from Emcraft I understood it will be
something before I can use gdb/strace.
 
> >Any help is appreciated,
> 
> The verbose elf2flt output may give some clues. You may need to
> instrument the kernel's fs/binfmt_flat.c code to match up reloc
> numbers though if nothing is obviously wrong in the verbose
> reloc information.

This will be harder for me at the moment, as compiling my own
kernel for this device is not working ATM. But if required I will
get it working.

best regards
 Waldemar

_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev