Hi Greg,
Greg Ungerer wrote,

> Hi Waldemar,
> 
> On 07/04/16 19:35, Waldemar Brodkorb wrote:
> > 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?
> 
> I am not sure which ones you are referring to?
 
I have attached a patch showing the problematic lines.

> >>> 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
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 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
diff --git a/elf2flt.c b/elf2flt.c
index 7d0e639..a415822 100644
--- a/elf2flt.c
+++ b/elf2flt.c
@@ -878,17 +878,6 @@ dump_symbols(symbols, number_of_symbols);
 #if defined(TARGET_arm)
                                case R_ARM_ABS32:
                                        relocation_needed = 1;
-                                       if (verbose)
-                                               fprintf(stderr,
-                                                       "%s vma=0x%x, "
-                                                       "value=0x%"BFD_VMA_FMT"x, "
-                                                       "address=0x%"BFD_VMA_FMT"x "
-                                                       "sym_addr=0x%x rs=0x%x, opcode=0x%x\n",
-                                                       "ABS32",
-                                                       sym_vma, (*(q->sym_ptr_ptr))->value,
-                                                       q->address, sym_addr,
-                                                       (*p)->howto->rightshift,
-                                                       *(uint32_t *)r_mem);
                                        sym_vma = bfd_section_vma(abs_bfd, sym_section);
                                        sym_addr += sym_vma + q->addend;
                                        break;
@@ -897,17 +886,6 @@ dump_symbols(symbols, number_of_symbols);
                                        /* Should be fine as is */
                                        break;
                                case R_ARM_PLT32:
-                                       if (verbose)
-                                               fprintf(stderr,
-                                                       "%s vma=0x%x, "
-                                                       "value=0x%"BFD_VMA_FMT"x, "
-                                                       "address=0x%"BFD_VMA_FMT"x "
-                                                       "sym_addr=0x%x rs=0x%x, opcode=0x%x\n",
-                                                       "PLT32",
-                                                       sym_vma, (*(q->sym_ptr_ptr))->value,
-                                                       q->address, sym_addr,
-                                                       (*p)->howto->rightshift,
-                                                       *(uint32_t *)r_mem);
                                case R_ARM_PC24:
                                        sym_vma = 0;
                                        sym_addr = (sym_addr-q->address)>>(*p)->howto->rightshift;

_______________________________________________
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

Reply via email to