Hi Waldemar,
On 06/05/16 05:06, Waldemar Brodkorb wrote:
Hi Greg,
Waldemar Brodkorb wrote,
Hi Greg,
Greg Ungerer wrote,
Attached is a kernel patch that modifies binfmt_flat to print
out the reloc number along with the reloc error. That way we can
map that back to the reloc entry number printed out in the verbose
output from elf2flt at compile time.
The stm32 is now working, here is the output with patched
kernel:
~ # /hello
[ 162.460000] BINFMT_FLAT: Loading file: /hello
[ 162.460000] Mapping is 90520000, Entry point is 45, data_start is 8984
[ 162.460000] Load /hello: TEXT=90520040-90528984 DATA=905289a0-9052e1b0
BSS=9052e1b0-9053240c
[ 162.460000] BINFMT_FLAT: reference 0x870000 to shared library 237, killing
hello!
SEGV
/hello
[ 11.230000] BINFMT_FLAT: reference 0x870000 to shared library 237, killing
hello!
SEGV
Hmm, on the stm32 with latest buildroot, I now get this errors.
But I just use UCLIBC_FORMAT_FLAT. The kernel defconfig used has
CONFIG_BINFMT_SHARED_FLAT enabled.
I disabled CONFIG_BINFMT_SHARED_FLAT in the kernel.
And now I get:
~ # /hello
[ 90.830000] BINFMT_FLAT: reloc[405] outside program 0xed870000 (0
- 0x123b0/0x8944), killing hello!
SEGV
Compiling with
./output/host/usr/bin/arm-buildroot-uclinux-uclibcgnueabi-gcc
-Wl,-elf2flt=-v -o hello hello.c -lpthread :
..
reloc[403] = 0xe140
RELOC[404]: offset=0x5724 symbol=frame_dummy+0x0 section=.text
size=0 fixup=0xac (reloc=0xe144)
reloc[404] = 0xe144
RELOC[405]: offset=0x5728 symbol=pthread_initialize+0x0
section=.text size=0 fixup=0x87ec (reloc=0xe148)
reloc[405] = 0xe148
RELOC[406]: offset=0x572c symbol=__do_global_dtors_aux+0x0
section=.text size=0 fixup=0x80 (reloc=0xe14c)
reloc[406] = 0xe14c
..
So pthread_initialize() is the problem?
I have an idea what is broken here now.
I am able to run this same test on qemu/versatile and get the
same result as you above with "hello" pthread test.
I think elf2flt is not properly handling R_ARM_TARGET1 relocation
types. And this causes a bad relocation calculation at runtime.
Can you try the attached patch?
This fixes it for me, and I can run "hello" and get expected result.
Regards
Greg
>From dedce8765d203c1c162a57e6259375e0b457173f Mon Sep 17 00:00:00 2001
From: Greg Ungerer <g...@linux-m68k.org>
Date: Fri, 19 Aug 2016 23:49:51 +1000
Subject: [PATCH] elf2flt: fix relocation support for R_ARM_TARGET types
R_ARM_TARGET1 (and I think R_ARM_TARGET2) relocation types should be
treated in the same way as R_ARM_ABS32. Fix them to write out the addend
to the flat binary in network byte order.
Signed-off-by: Greg Ungerer <g...@uclinux.org>
---
elf2flt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/elf2flt.c b/elf2flt.c
index 5ae7dd9..3f31569 100644
--- a/elf2flt.c
+++ b/elf2flt.c
@@ -1505,7 +1505,9 @@ DIS29_RELOCATION:
(((*p)->howto->type != R_ARM_PC24) &&
((*p)->howto->type != R_ARM_PLT32)))
tmp.c[i3] = (hl >> 24) & 0xff;
- if ((*p)->howto->type == R_ARM_ABS32)
+ if (((*p)->howto->type == R_ARM_ABS32) ||
+ ((*p)->howto->type == R_ARM_TARGET1) ||
+ ((*p)->howto->type == R_ARM_TARGET2))
*(uint32_t *)r_mem = htonl(hl);
else
*(uint32_t *)r_mem = tmp.l;
--
1.9.1
_______________________________________________
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
