Discussion:
BINFMT_FLAT: reloc outside program
(too old to reply)
Waldemar Brodkorb
2016-04-05 10:49:27 UTC
Permalink
Hi uClinux/elf2flt devs,

How can I debug an issue with the following error while
executing:
~ # ./hello
BINFMT_FLAT: reloc outside program 0xb5890000 (0 - 0x125a4/0x8b0c),
killing hello!
SEGV

The target is an ARM Cortex-M4 device. The error is only happening
when libpthread from uClibc-ng is used in the binary. Non-threading
applications are working fine. (Linuxthreads.old used)
The problem was reported by Thomas Petazzoni from Buildroot project.

On the build system I used this example code:
http://timmurphy.org/2010/05/04/pthreads-in-c-a-minimal-working-example/

$ /usr/bin/arm-openadk-uclinux-uclibceabi-gcc -o hello hello.c -lpthread
$ /usr/bin/arm-openadk-uclinux-uclibceabi-flthdr -k hello
$ /usr/bin/arm-openadk-uclinux-uclibceabi-flthdr -p hello
hello
Magic: bFLT
Rev: 4
Build Date: Tue Apr 5 12:28:25 2016
Entry: 0x45
Data Start: 0x8b4c
Data End: 0xe384
BSS End: 0x125e0
Stack Size: 0x1000
Reloc Start: 0xe384
Reloc Count: 0x197
Flags: 0x11 ( Load-to-Ram Kernel-Traced-Load )

On the target system:
~ # ./hello
BINFMT_FLAT: Loading file: ./hello
Mapping is 70020000, Entry point is 45, data_start is 8b4c
Load ./hello: TEXT=70020040-70028b4c DATA=70028b50-7002e388
BSS=7002e388-700325e4
BINFMT_FLAT: reloc outside program 0xb5890000 (0 - 0x125a4/0x8b0c),
killing hello!
SEGV

You can find readelf, objdump -x, objdump -D and the source of
hello.c here:
http://debug.openadk.org/arm-pthreads/

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!

gdbserver (gdb 7.11) does not compile for me as it uses fork():
build-gnulib-gdbserver/import/libgnu.a
build-libiberty-gdbserver/libiberty.a -lthread_db
linux-low.o: In function `linux_create_inferior':
linux-low.c:(.text+0x25d2): undefined reference to `fork'
linux-ptrace.o: In function `linux_child_function':
linux-ptrace.c:(.text+0x24): undefined reference to `fork'
linux-ptrace.o: In function `linux_check_ptrace_features':
linux-ptrace.c:(.text+0x10a): undefined reference to `fork'
thread-db.o: In function `thread_db_init':
thread-db.c:(.text+0x520): undefined reference to `td_thr_tlsbase'
collect2: error: ld returned 1 exit status

I searched the internet and found that it might be stack size
related. But even compiling example code and C library with
-Wl,-elf2flt=-s16384 didn't help.

Any help is appreciated,
thanks
Waldemar
_______________________________________________
uClinux-dev mailing list
uClinux-***@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-***@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Greg Ungerer
2016-04-07 05:25:41 UTC
Permalink
Hi Waldemar,
Post by Waldemar Brodkorb
Hi uClinux/elf2flt devs,
How can I debug an issue with the following error while
~ # ./hello
BINFMT_FLAT: reloc outside program 0xb5890000 (0 - 0x125a4/0x8b0c),
killing hello!
SEGV
The target is an ARM Cortex-M4 device. The error is only happening
when libpthread from uClibc-ng is used in the binary. Non-threading
applications are working fine. (Linuxthreads.old used)
The problem was reported by Thomas Petazzoni from Buildroot project.
http://timmurphy.org/2010/05/04/pthreads-in-c-a-minimal-working-example/
$ /usr/bin/arm-openadk-uclinux-uclibceabi-gcc -o hello hello.c -lpthread
$ /usr/bin/arm-openadk-uclinux-uclibceabi-flthdr -k hello
$ /usr/bin/arm-openadk-uclinux-uclibceabi-flthdr -p hello
hello
Magic: bFLT
Rev: 4
Build Date: Tue Apr 5 12:28:25 2016
Entry: 0x45
Data Start: 0x8b4c
Data End: 0xe384
BSS End: 0x125e0
Stack Size: 0x1000
Reloc Start: 0xe384
Reloc Count: 0x197
Flags: 0x11 ( Load-to-Ram Kernel-Traced-Load )
~ # ./hello
BINFMT_FLAT: Loading file: ./hello
Mapping is 70020000, Entry point is 45, data_start is 8b4c
Load ./hello: TEXT=70020040-70028b4c DATA=70028b50-7002e388
BSS=7002e388-700325e4
BINFMT_FLAT: reloc outside program 0xb5890000 (0 - 0x125a4/0x8b0c),
killing hello!
SEGV
You can find readelf, objdump -x, objdump -D and the source of
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).
Post by Waldemar Brodkorb
~ # ./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.
Post by Waldemar Brodkorb
build-gnulib-gdbserver/import/libgnu.a
build-libiberty-gdbserver/libiberty.a -lthread_db
linux-low.c:(.text+0x25d2): undefined reference to `fork'
linux-ptrace.c:(.text+0x24): undefined reference to `fork'
linux-ptrace.c:(.text+0x10a): undefined reference to `fork'
thread-db.c:(.text+0x520): undefined reference to `td_thr_tlsbase'
collect2: error: ld returned 1 exit status
That won't help you here either (at least for this specific
problem). It is the exec step this program that is failing.
Post by Waldemar Brodkorb
I searched the internet and found that it might be stack size
related. But even compiling example code and C library with
-Wl,-elf2flt=-s16384 didn't help.
Ok, that is always a good thing to try first.
Post by Waldemar Brodkorb
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.

Regards
Greg


_______________________________________________
uClinux-dev mailing list
uClinux-***@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-***@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Waldemar Brodkorb
2016-04-07 09:35:41 UTC
Permalink
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
Post by Waldemar Brodkorb
You can find readelf, objdump -x, objdump -D and the source of
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?
Post by Greg Ungerer
Post by Waldemar Brodkorb
~ # ./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.
Post by Greg Ungerer
Post by Waldemar Brodkorb
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
Greg Ungerer
2016-04-15 07:13:54 UTC
Permalink
Hi Waldemar,
Post by Waldemar Brodkorb
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
Post by Waldemar Brodkorb
You can find readelf, objdump -x, objdump -D and the source of
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).
~ # ./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?
I am not sure which ones you are referring to?
Post by Waldemar Brodkorb
Post by Greg Ungerer
Post by Waldemar Brodkorb
~ # ./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.
Post by Greg Ungerer
Post by Waldemar Brodkorb
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.
I couldn't see the problem in amongst that verbose output.
I would really want to see what reloc number the kernel loader
is barfing on to make sense of it.

I don't have a working ARM nommu target build at the moment,
so I don't have any way to try this myself. I will try and
put something together so I can run it under qemu to debug it
further.

Regards
Greg
Post by Waldemar Brodkorb
_______________________________________________
uClinux-dev mailing list
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-***@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-***@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Waldemar Brodkorb
2016-04-16 15:38:34 UTC
Permalink
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
Hi Waldemar,
Post by Waldemar Brodkorb
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
Post by Waldemar Brodkorb
You can find readelf, objdump -x, objdump -D and the source of
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).
~ # ./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?
I am not sure which ones you are referring to?
I have attached a patch showing the problematic lines.
Post by Greg Ungerer
Post by Waldemar Brodkorb
Post by Greg Ungerer
Post by Waldemar Brodkorb
~ # ./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.
Post by Greg Ungerer
Post by Waldemar Brodkorb
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.
I couldn't see the problem in amongst that verbose output.
I would really want to see what reloc number the kernel loader
is barfing on to make sense of it.
How could I generate the information for you? Do you have
a kernel patch I would need to apply? I can bootup a kernel
and execute code, I just can't type anything into the serial
console. And I could ask Thomas to test something on his device.
I think my STM is slightly different to his device, I also need
to change some USB ID in OpenOCD to flash. May be there is also some
difference in the IRQ number handling the serial device.
Post by Greg Ungerer
I don't have a working ARM nommu target build at the moment,
so I don't have any way to try this myself. I will try and
put something together so I can run it under qemu to debug it
further.
You could try latest buildroot to generate an image for
STM32 F4 discovery, sth like this:
http://www2.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-discovery-kits/32f429idiscovery.html

I am not sure any Qemu Cortex-M3/4 system emulation is
available.

best regards
Waldema
Greg Ungerer
2016-04-18 07:28:31 UTC
Permalink
Hi Waldemar,
Post by Waldemar Brodkorb
Greg Ungerer wrote,
Post by Greg Ungerer
Post by Waldemar Brodkorb
Greg Ungerer wrote,
Post by Greg Ungerer
Post by Waldemar Brodkorb
You can find readelf, objdump -x, objdump -D and the source of
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).
~ # ./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?
I am not sure which ones you are referring to?
I have attached a patch showing the problematic lines.
Ok, I see. My first thought is that they may in fact be
showing a problem right here. Can you possibly debug a little
here and determine which of the printf args are causing the
segfault?
Post by Waldemar Brodkorb
Post by Greg Ungerer
Post by Waldemar Brodkorb
Post by Greg Ungerer
Post by Waldemar Brodkorb
~ # ./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.
Post by Greg Ungerer
Post by Waldemar Brodkorb
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.
I couldn't see the problem in amongst that verbose output.
I would really want to see what reloc number the kernel loader
is barfing on to make sense of it.
How could I generate the information for you? Do you have
a kernel patch I would need to apply? I can bootup a kernel
and execute code, I just can't type anything into the serial
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.
Post by Waldemar Brodkorb
console. And I could ask Thomas to test something on his device.
I think my STM is slightly different to his device, I also need
to change some USB ID in OpenOCD to flash. May be there is also some
difference in the IRQ number handling the serial device.
I don't expect that the specific target really has an impact here.
It feels more like a general ARM elf2lft problem.
Post by Waldemar Brodkorb
Post by Greg Ungerer
I don't have a working ARM nommu target build at the moment,
so I don't have any way to try this myself. I will try and
put something together so I can run it under qemu to debug it
further.
You could try latest buildroot to generate an image for
http://www2.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-discovery-kits/32f429idiscovery.html
I have used the smaller ST parts (not with Linux), but not this one.
Post by Waldemar Brodkorb
I am not sure any Qemu Cortex-M3/4 system emulation is
available.
Do you know of any qemu target machines that work out-of-the-box
with a stock linux kernel with MMU disabled?

I used to use the gdb/ARMulator many years ago, but the kernel
target machine (Atmel/at91eb01) is long gone in modern kernel
version.

Regards
Greg
Waldemar Brodkorb
2016-04-22 22:50:09 UTC
Permalink
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
Post by Waldemar Brodkorb
How could I generate the information for you? Do you have
a kernel patch I would need to apply? I can bootup a kernel
and execute code, I just can't type anything into the serial
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.
Thanks for the patch, will try it.
Post by Greg Ungerer
Post by Waldemar Brodkorb
I am not sure any Qemu Cortex-M3/4 system emulation is
available.
Do you know of any qemu target machines that work out-of-the-box
with a stock linux kernel with MMU disabled?
No.
Post by Greg Ungerer
I used to use the gdb/ARMulator many years ago, but the kernel
target machine (Atmel/at91eb01) is long gone in modern kernel
version.
I tried three different qemu forks, but they all only provide
system level emulation for bare-metal apps. Skyeye crashes for me
and recent GDB doesn't contain the old Armulator stuff.

I tried Qemu mainline to bootup versatilepb/vexpress Linux kernel
without MMU, but get no output.

I think the situation is really bad. I will try to get the patch
tested on my STM32 board.

best regards
Waldemar
_______________________________________________
uClinux-dev mailing list
uClinux-***@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-***@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Greg Ungerer
2016-08-11 11:38:50 UTC
Permalink
Hi Waldemar,
Post by Waldemar Brodkorb
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
Post by Waldemar Brodkorb
How could I generate the information for you? Do you have
a kernel patch I would need to apply? I can bootup a kernel
and execute code, I just can't type anything into the serial
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.
Thanks for the patch, will try it.
Post by Greg Ungerer
Post by Waldemar Brodkorb
I am not sure any Qemu Cortex-M3/4 system emulation is
available.
Do you know of any qemu target machines that work out-of-the-box
with a stock linux kernel with MMU disabled?
No.
Post by Greg Ungerer
I used to use the gdb/ARMulator many years ago, but the kernel
target machine (Atmel/at91eb01) is long gone in modern kernel
version.
I tried three different qemu forks, but they all only provide
system level emulation for bare-metal apps. Skyeye crashes for me
and recent GDB doesn't contain the old Armulator stuff.
I tried Qemu mainline to bootup versatilepb/vexpress Linux kernel
without MMU, but get no output.
Looking into the other ARM flat problem, I figured we need to get
this problem solved as well.

Turns out it is not too hard to get a Versatile target built
and running on qemu in no-MMU mode. The only real change required
is the attached patch - which fixes the IO device addressing problem.

With this patch and starting with the versatile_defconfig you
only need a couple of config changes and it will run on the
versatile target in qemu. You need to disable CONFIG_MMU
and set the DRAM sizing (base at 0, size 128MB).

This patch is against a linux-4.4 kernel, and it looks like the
versatile target has gone device tree from 4.5 and newer - so
this patch won't apply or work on them as is.

Regards
Greg
Waldemar Brodkorb
2016-08-16 04:59:34 UTC
Permalink
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
Hi Waldemar,
Post by Waldemar Brodkorb
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
Post by Waldemar Brodkorb
How could I generate the information for you? Do you have
a kernel patch I would need to apply? I can bootup a kernel
and execute code, I just can't type anything into the serial
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.
Thanks for the patch, will try it.
Post by Greg Ungerer
Post by Waldemar Brodkorb
I am not sure any Qemu Cortex-M3/4 system emulation is
available.
Do you know of any qemu target machines that work out-of-the-box
with a stock linux kernel with MMU disabled?
No.
Post by Greg Ungerer
I used to use the gdb/ARMulator many years ago, but the kernel
target machine (Atmel/at91eb01) is long gone in modern kernel
version.
I tried three different qemu forks, but they all only provide
system level emulation for bare-metal apps. Skyeye crashes for me
and recent GDB doesn't contain the old Armulator stuff.
I tried Qemu mainline to bootup versatilepb/vexpress Linux kernel
without MMU, but get no output.
Looking into the other ARM flat problem, I figured we need to get
this problem solved as well.
Turns out it is not too hard to get a Versatile target built
and running on qemu in no-MMU mode. The only real change required
is the attached patch - which fixes the IO device addressing problem.
With this patch and starting with the versatile_defconfig you
only need a couple of config changes and it will run on the
versatile target in qemu. You need to disable CONFIG_MMU
and set the DRAM sizing (base at 0, size 128MB).
This patch is against a linux-4.4 kernel, and it looks like the
versatile target has gone device tree from 4.5 and newer - so
this patch won't apply or work on them as is.
Can you show us the commandline you use? What -cpu do you use?

Thanks
Waldemar

_______________________________________________
uClinux-dev mailing list
uClinux-***@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-***@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Greg Ungerer
2016-08-18 03:13:50 UTC
Permalink
Hi Waldemar,
Post by Waldemar Brodkorb
Greg Ungerer wrote,
Post by Greg Ungerer
Hi Waldemar,
Post by Waldemar Brodkorb
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
Post by Waldemar Brodkorb
How could I generate the information for you? Do you have
a kernel patch I would need to apply? I can bootup a kernel
and execute code, I just can't type anything into the serial
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.
Thanks for the patch, will try it.
Post by Greg Ungerer
Post by Waldemar Brodkorb
I am not sure any Qemu Cortex-M3/4 system emulation is
available.
Do you know of any qemu target machines that work out-of-the-box
with a stock linux kernel with MMU disabled?
No.
Post by Greg Ungerer
I used to use the gdb/ARMulator many years ago, but the kernel
target machine (Atmel/at91eb01) is long gone in modern kernel
version.
I tried three different qemu forks, but they all only provide
system level emulation for bare-metal apps. Skyeye crashes for me
and recent GDB doesn't contain the old Armulator stuff.
I tried Qemu mainline to bootup versatilepb/vexpress Linux kernel
without MMU, but get no output.
Looking into the other ARM flat problem, I figured we need to get
this problem solved as well.
Turns out it is not too hard to get a Versatile target built
and running on qemu in no-MMU mode. The only real change required
is the attached patch - which fixes the IO device addressing problem.
With this patch and starting with the versatile_defconfig you
only need a couple of config changes and it will run on the
versatile target in qemu. You need to disable CONFIG_MMU
and set the DRAM sizing (base at 0, size 128MB).
This patch is against a linux-4.4 kernel, and it looks like the
versatile target has gone device tree from 4.5 and newer - so
this patch won't apply or work on them as is.
Can you show us the commandline you use? What -cpu do you use?
To run qemu I use:

qemu-system-arm -M versatilepb -nographic -kernel images/zImage -append "console=ttyAMA0,115200"

The running system reports:

CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00091176
CPU: VIVT data cache, VIVT instruction cache
Machine: ARM-Versatile PB

So its an ARM926 - but I didn't specify any CPU to qemu, I just
let it default to whatever is the versatilepb qemu default.

Attached is the linux kernel config I used to generate kernel.

Note that I have had to make a couple of changes to elf2flt to get
apps working. I'll send some emails about those soon. But that
doesn't affect getting the kernel running on qemu.

Regards
Greg
Waldemar Brodkorb
2016-08-24 21:34:06 UTC
Permalink
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
Hi Waldemar,
Post by Waldemar Brodkorb
Greg Ungerer wrote,
Post by Greg Ungerer
Hi Waldemar,
Post by Waldemar Brodkorb
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
Post by Waldemar Brodkorb
How could I generate the information for you? Do you have
a kernel patch I would need to apply? I can bootup a kernel
and execute code, I just can't type anything into the serial
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.
Thanks for the patch, will try it.
Post by Greg Ungerer
Post by Waldemar Brodkorb
I am not sure any Qemu Cortex-M3/4 system emulation is
available.
Do you know of any qemu target machines that work out-of-the-box
with a stock linux kernel with MMU disabled?
No.
Post by Greg Ungerer
I used to use the gdb/ARMulator many years ago, but the kernel
target machine (Atmel/at91eb01) is long gone in modern kernel
version.
I tried three different qemu forks, but they all only provide
system level emulation for bare-metal apps. Skyeye crashes for me
and recent GDB doesn't contain the old Armulator stuff.
I tried Qemu mainline to bootup versatilepb/vexpress Linux kernel
without MMU, but get no output.
Looking into the other ARM flat problem, I figured we need to get
this problem solved as well.
Turns out it is not too hard to get a Versatile target built
and running on qemu in no-MMU mode. The only real change required
is the attached patch - which fixes the IO device addressing problem.
With this patch and starting with the versatile_defconfig you
only need a couple of config changes and it will run on the
versatile target in qemu. You need to disable CONFIG_MMU
and set the DRAM sizing (base at 0, size 128MB).
This patch is against a linux-4.4 kernel, and it looks like the
versatile target has gone device tree from 4.5 and newer - so
this patch won't apply or work on them as is.
Can you show us the commandline you use? What -cpu do you use?
qemu-system-arm -M versatilepb -nographic -kernel images/zImage -append "console=ttyAMA0,115200"
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00091176
CPU: VIVT data cache, VIVT instruction cache
Machine: ARM-Versatile PB
So its an ARM926 - but I didn't specify any CPU to qemu, I just
let it default to whatever is the versatilepb qemu default.
Attached is the linux kernel config I used to generate kernel.
Note that I have had to make a couple of changes to elf2flt to get
apps working. I'll send some emails about those soon. But that
doesn't affect getting the kernel running on qemu.
I can't get it working.
Can you explain what toolchain do you use?
gcc version? binutils version? soft-float toolchain?
Are you using arm or thumb instructions?
Can you show me gcc -v of your cross-compiler?

best regards
Waldemar
_______________________________________________
uClinux-dev mailing list
uClinux-***@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-***@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Greg Ungerer
2016-08-25 00:29:08 UTC
Permalink
Hi Waldemar,
Post by Waldemar Brodkorb
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
Hi Waldemar,
Post by Waldemar Brodkorb
Greg Ungerer wrote,
Post by Greg Ungerer
Hi Waldemar,
Post by Waldemar Brodkorb
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
Post by Waldemar Brodkorb
How could I generate the information for you? Do you have
a kernel patch I would need to apply? I can bootup a kernel
and execute code, I just can't type anything into the serial
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.
Thanks for the patch, will try it.
Post by Greg Ungerer
Post by Waldemar Brodkorb
I am not sure any Qemu Cortex-M3/4 system emulation is
available.
Do you know of any qemu target machines that work out-of-the-box
with a stock linux kernel with MMU disabled?
No.
Post by Greg Ungerer
I used to use the gdb/ARMulator many years ago, but the kernel
target machine (Atmel/at91eb01) is long gone in modern kernel
version.
I tried three different qemu forks, but they all only provide
system level emulation for bare-metal apps. Skyeye crashes for me
and recent GDB doesn't contain the old Armulator stuff.
I tried Qemu mainline to bootup versatilepb/vexpress Linux kernel
without MMU, but get no output.
Looking into the other ARM flat problem, I figured we need to get
this problem solved as well.
Turns out it is not too hard to get a Versatile target built
and running on qemu in no-MMU mode. The only real change required
is the attached patch - which fixes the IO device addressing problem.
With this patch and starting with the versatile_defconfig you
only need a couple of config changes and it will run on the
versatile target in qemu. You need to disable CONFIG_MMU
and set the DRAM sizing (base at 0, size 128MB).
This patch is against a linux-4.4 kernel, and it looks like the
versatile target has gone device tree from 4.5 and newer - so
this patch won't apply or work on them as is.
Can you show us the commandline you use? What -cpu do you use?
qemu-system-arm -M versatilepb -nographic -kernel images/zImage -append "console=ttyAMA0,115200"
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00091176
CPU: VIVT data cache, VIVT instruction cache
Machine: ARM-Versatile PB
So its an ARM926 - but I didn't specify any CPU to qemu, I just
let it default to whatever is the versatilepb qemu default.
Attached is the linux kernel config I used to generate kernel.
Note that I have had to make a couple of changes to elf2flt to get
apps working. I'll send some emails about those soon. But that
doesn't affect getting the kernel running on qemu.
I can't get it working.
Can you explain what toolchain do you use?
My own manually compiled toolchain.
Post by Waldemar Brodkorb
gcc version? binutils version? soft-float toolchain?
gcc-5.4.0
binutils-2.26

Toolchain targeted at arm-uclinuxeabi using hard-float
(as in --with-float=hard gcc configuration)
Post by Waldemar Brodkorb
Are you using arm or thumb instructions?
ARM only.
Post by Waldemar Brodkorb
Can you show me gcc -v of your cross-compiler?
Using built-in specs.
COLLECT_GCC=arm-uclinuxeabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/arm-uclinuxeabi/5.4.0/lto-wrapper
Target: arm-uclinuxeabi
Configured with: ../configure --target=arm-uclinuxeabi --with-float=hard --enable-multilib --with-system-zlib --disable-libsanitizer --enable-languages=c,c++ --prefix=/usr/local
Thread model: single
gcc version 5.4.0 (GCC)

Kernel is a pristine linux-4.4 with only the hardware IO patch
listed earlier in the thread applied.

In the end I didn't need to modify elf2flt to get a working system
using an arm-uclinuxeabi toolchain.

Regards
Greg



_______________________________________________
uClinux-dev mailing list
uClinux-***@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-***@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Waldemar Brodkorb
2016-08-27 11:24:11 UTC
Permalink
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
Hi Waldemar,
Post by Waldemar Brodkorb
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
Hi Waldemar,
Post by Waldemar Brodkorb
Greg Ungerer wrote,
Post by Greg Ungerer
Hi Waldemar,
Post by Waldemar Brodkorb
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
Post by Waldemar Brodkorb
How could I generate the information for you? Do you have
a kernel patch I would need to apply? I can bootup a kernel
and execute code, I just can't type anything into the serial
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.
Thanks for the patch, will try it.
Post by Greg Ungerer
Post by Waldemar Brodkorb
I am not sure any Qemu Cortex-M3/4 system emulation is
available.
Do you know of any qemu target machines that work out-of-the-box
with a stock linux kernel with MMU disabled?
No.
Post by Greg Ungerer
I used to use the gdb/ARMulator many years ago, but the kernel
target machine (Atmel/at91eb01) is long gone in modern kernel
version.
I tried three different qemu forks, but they all only provide
system level emulation for bare-metal apps. Skyeye crashes for me
and recent GDB doesn't contain the old Armulator stuff.
I tried Qemu mainline to bootup versatilepb/vexpress Linux kernel
without MMU, but get no output.
Looking into the other ARM flat problem, I figured we need to get
this problem solved as well.
Turns out it is not too hard to get a Versatile target built
and running on qemu in no-MMU mode. The only real change required
is the attached patch - which fixes the IO device addressing problem.
With this patch and starting with the versatile_defconfig you
only need a couple of config changes and it will run on the
versatile target in qemu. You need to disable CONFIG_MMU
and set the DRAM sizing (base at 0, size 128MB).
This patch is against a linux-4.4 kernel, and it looks like the
versatile target has gone device tree from 4.5 and newer - so
this patch won't apply or work on them as is.
Can you show us the commandline you use? What -cpu do you use?
qemu-system-arm -M versatilepb -nographic -kernel images/zImage -append "console=ttyAMA0,115200"
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00091176
CPU: VIVT data cache, VIVT instruction cache
Machine: ARM-Versatile PB
So its an ARM926 - but I didn't specify any CPU to qemu, I just
let it default to whatever is the versatilepb qemu default.
Attached is the linux kernel config I used to generate kernel.
Note that I have had to make a couple of changes to elf2flt to get
apps working. I'll send some emails about those soon. But that
doesn't affect getting the kernel running on qemu.
I can't get it working.
Can you explain what toolchain do you use?
My own manually compiled toolchain.
Post by Waldemar Brodkorb
gcc version? binutils version? soft-float toolchain?
gcc-5.4.0
binutils-2.26
Toolchain targeted at arm-uclinuxeabi using hard-float
(as in --with-float=hard gcc configuration)
Post by Waldemar Brodkorb
Are you using arm or thumb instructions?
ARM only.
Post by Waldemar Brodkorb
Can you show me gcc -v of your cross-compiler?
Using built-in specs.
COLLECT_GCC=arm-uclinuxeabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/arm-uclinuxeabi/5.4.0/lto-wrapper
Target: arm-uclinuxeabi
Configured with: ../configure --target=arm-uclinuxeabi --with-float=hard --enable-multilib --with-system-zlib --disable-libsanitizer --enable-languages=c,c++ --prefix=/usr/local
Thread model: single
gcc version 5.4.0 (GCC)
Kernel is a pristine linux-4.4 with only the hardware IO patch
listed earlier in the thread applied.
In the end I didn't need to modify elf2flt to get a working system
using an arm-uclinuxeabi toolchain.
Thanks for the background information, finally I can get it working,
too. Thanks!

Waldemar
_______________________________________________
uClinux-dev mailing list
uClinux-***@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-***@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Waldemar Brodkorb
2016-05-05 18:20:16 UTC
Permalink
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
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.

Any idea?

best regards
Waldemar


_______________________________________________
uClinux-dev mailing list
uClinux-***@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-***@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Waldemar Brodkorb
2016-05-05 19:06:02 UTC
Permalink
Hi Greg,
Waldemar Brodkorb wrote,
Post by Waldemar Brodkorb
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
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
~ # /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?

best regards
Waldemar
_______________________________________________
uClinux-dev mailing list
uClinux-***@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-***@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Greg Ungerer
2016-05-10 06:33:21 UTC
Permalink
Hi Waldemar,
Post by Waldemar Brodkorb
Hi Greg,
Waldemar Brodkorb wrote,
Post by Waldemar Brodkorb
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
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
~ # /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.
~ # /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
..
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?
Sure does look that way. I am not sure why looking at the above
details though.

Can you run again with the "Kernel-Traced-Load" flag set on the
hello program (so run the flthdr -k on it first). I want to see
what the actual memory regions allocated where and how far out
of those bounds the relocation ended up.

Regards
Greg


_______________________________________________
uClinux-dev mailing list
uClinux-***@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-***@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Waldemar Brodkorb
2016-05-10 18:57:31 UTC
Permalink
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
Hi Waldemar,
Post by Waldemar Brodkorb
I disabled CONFIG_BINFMT_SHARED_FLAT in the kernel.
~ # /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
..
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?
Sure does look that way. I am not sure why looking at the above
details though.
Can you run again with the "Kernel-Traced-Load" flag set on the
hello program (so run the flthdr -k on it first). I want to see
what the actual memory regions allocated where and how far out
of those bounds the relocation ended up.
Here it is:
~ # /hello
[ 57.910000] BINFMT_FLAT: Loading file: /hello
[ 57.910000] Mapping is 90580000, Entry point is 45, data_start is 8984
[ 57.910000] Load /hello: TEXT=90580040-90588984 DATA=905889a0-9058e1b0 BSS=9058e1b0-9059240c
[ 57.910000] BINFMT_FLAT: reloc[405] outside program 0xed870000 (0 - 0x123b0/0x8944), killing hello!
SEGV

The same hello world application works on Qemu m68k somehow. It starts and
get SIGILL, but at least not a relocation problem.

best regards
Waldemar
_______________________________________________
uClinux-dev mailing list
uClinux-***@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-***@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Greg Ungerer
2016-05-13 13:17:52 UTC
Permalink
Hi Waldemar,
Post by Waldemar Brodkorb
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
Hi Waldemar,
Post by Waldemar Brodkorb
I disabled CONFIG_BINFMT_SHARED_FLAT in the kernel.
~ # /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
..
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?
Sure does look that way. I am not sure why looking at the above
details though.
Can you run again with the "Kernel-Traced-Load" flag set on the
hello program (so run the flthdr -k on it first). I want to see
what the actual memory regions allocated where and how far out
of those bounds the relocation ended up.
~ # /hello
[ 57.910000] BINFMT_FLAT: Loading file: /hello
[ 57.910000] Mapping is 90580000, Entry point is 45, data_start is 8984
[ 57.910000] Load /hello: TEXT=90580040-90588984 DATA=905889a0-9058e1b0 BSS=9058e1b0-9059240c
[ 57.910000] BINFMT_FLAT: reloc[405] outside program 0xed870000 (0 - 0x123b0/0x8944), killing hello!
SEGV
Thanks for that. When I get a spare minute I will dig into it
and see if I can make any sense of that. It is obviously way out
of the expected range.
Post by Waldemar Brodkorb
The same hello world application works on Qemu m68k somehow. It starts and
get SIGILL, but at least not a relocation problem.
If you want to post more details on that I can have a look
at that too.

Regards
Greg
_______________________________________________
uClinux-dev mailing list
uClinux-***@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-***@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Waldemar Brodkorb
2016-06-08 20:49:58 UTC
Permalink
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
Thanks for that. When I get a spare minute I will dig into it
and see if I can make any sense of that. It is obviously way out
of the expected range.
Any spare minute to check what is wrong here?

best regards
Waldemar
_______________________________________________
uClinux-dev mailing list
uClinux-***@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-***@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Greg Ungerer
2016-06-15 12:28:02 UTC
Permalink
Hi Waldemar,
Post by Waldemar Brodkorb
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
Thanks for that. When I get a spare minute I will dig into it
and see if I can make any sense of that. It is obviously way out
of the expected range.
Any spare minute to check what is wrong here?
Sorry, no, not yet.

Regards
Greg
_______________________________________________
uClinux-dev mailing list
uClinux-***@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-***@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Greg Ungerer
2016-08-19 13:59:36 UTC
Permalink
Hi Waldemar,
Post by Waldemar Brodkorb
Hi Greg,
Waldemar Brodkorb wrote,
Post by Waldemar Brodkorb
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
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
~ # /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.
~ # /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
..
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
Waldemar Brodkorb
2016-08-24 21:30:15 UTC
Permalink
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
Hi Waldemar,
Post by Waldemar Brodkorb
Hi Greg,
Waldemar Brodkorb wrote,
Post by Waldemar Brodkorb
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
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
~ # /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.
~ # /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
..
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.
Thanks. This works for me, too.

Great that we have a solution for it!
Please push it :=)

best regards
Waldemar
_______________________________________________
uClinux-dev mailing list
uClinux-***@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-***@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Greg Ungerer
2016-08-25 01:24:26 UTC
Permalink
Post by Waldemar Brodkorb
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
Hi Waldemar,
Post by Waldemar Brodkorb
Hi Greg,
Waldemar Brodkorb wrote,
Post by Waldemar Brodkorb
Hi Greg,
Greg Ungerer wrote,
Post by Greg Ungerer
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
~ # /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.
~ # /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
..
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.
Thanks. This works for me, too.
Great that we have a solution for it!
Please push it :=)
Pushed up to the git tree on github.
(https://github.com/uclinux-dev/elf2flt)

Regards
Greg



_______________________________________________
uClinux-dev mailing list
uClinux-***@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-***@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Loading...