Hi Waldemar,
On 17/04/16 01:38, Waldemar Brodkorb wrote:
> Greg Ungerer wrote,
>> On 07/04/16 19:35, Waldemar Brodkorb wrote:
>>> 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?
>>
>> 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?
>>>>> 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.
>>
>> 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.
> 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.
>> 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 have used the smaller ST parts (not with Linux), but not this one.
> 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
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index f723cd3..17544c1 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -310,7 +310,7 @@ out_free:
/****************************************************************************/
static unsigned long
-calc_reloc(unsigned long r, struct lib_info *p, int curid, int internalp)
+calc_reloc(unsigned long r, struct lib_info *p, int curid, int internalp, int num)
{
unsigned long addr;
int id;
@@ -358,7 +358,7 @@ calc_reloc(unsigned long r, struct lib_info *p, int curid, int internalp)
text_len = p->lib_list[id].text_len;
if (!flat_reloc_valid(r, start_brk - start_data + text_len)) {
- printk("BINFMT_FLAT: reloc outside program 0x%x (0 - 0x%x/0x%x)",
+ printk("BINFMT_FLAT: reloc[%d] outside program 0x%x (0 - 0x%x/0x%x)", num,
(int) r,(int)(start_brk-start_data+text_len),(int)text_len);
goto failed;
}
@@ -717,10 +717,10 @@ static int load_flat_file(struct linux_binprm * bprm,
* image.
*/
if (flags & FLAT_FLAG_GOTPIC) {
- for (rp = (unsigned long *)datapos; *rp != 0xffffffff; rp++) {
+ for (i = 0, rp = (unsigned long *)datapos; *rp != 0xffffffff; i++, rp++) {
unsigned long addr;
if (*rp) {
- addr = calc_reloc(*rp, libinfo, id, 0);
+ addr = calc_reloc(*rp, libinfo, id, 0, i);
if (addr == RELOC_FAILED) {
ret = -ENOEXEC;
goto err;
@@ -753,7 +753,7 @@ static int load_flat_file(struct linux_binprm * bprm,
if (flat_set_persistent (relval, &persistent))
continue;
addr = flat_get_relocate_addr(relval);
- rp = (unsigned long *) calc_reloc(addr, libinfo, id, 1);
+ rp = (unsigned long *) calc_reloc(addr, libinfo, id, 1, i);
if (rp == (unsigned long *)RELOC_FAILED) {
ret = -ENOEXEC;
goto err;
@@ -769,7 +769,7 @@ static int load_flat_file(struct linux_binprm * bprm,
*/
if ((flags & FLAT_FLAG_GOTPIC) == 0)
addr = ntohl(addr);
- addr = calc_reloc(addr, libinfo, id, 0);
+ addr = calc_reloc(addr, libinfo, id, 0, i);
if (addr == RELOC_FAILED) {
ret = -ENOEXEC;
goto err;
_______________________________________________
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
