Greg Ungerer wrote,

> Hi Waldemar,
> 
> On 25/08/16 07:35, Waldemar Brodkorb wrote:
> > Hi,
> > Greg Ungerer wrote,
> > 
> >> Hi Waldemar,
> >>
> >> On 19/08/16 08:48, Waldemar Brodkorb wrote:
> >>> Hi Greg,
> >>> Greg Ungerer wrote,
> >>>
> >>>> Hi Waldemar,
> >>>>
> >>>> On 19/03/16 13:53, Greg Ungerer wrote:
> >>>>> Hi Waldemar,
> >>>>>
> >>>>> On 14/03/16 15:01, Waldemar Brodkorb wrote:
> >>>>>> Add patchset from ptxdist which is required to produce working
> >>>>>> ARM flat binaries. Tested with busybox on Kinetis K70.
> >>>>>>
> >>>>>> Signed-off-by: Waldemar Brodkorb <w...@openadk.org>
> >>>>>
> >>>>> Thanks. Applied to the github elf2flt repository (with Thomas'
> >>>>> Tested-by).
> >>>>
> >>>> The adding of the ARM.eidx section in this patch breaks binaries
> >>>> that have a global offset table (GOT). I propose the attached fix
> >>>> that puts it within the data section proper - and not effectively
> >>>> at the start of the data section.
> >>>>
> >>>> The original patch would have no impact on fully relocated
> >>>> binaries, generally only those compiled with -fpic or similar.
> >>>
> >>> I tested your patch with Buildroot on a STM32F29 device, but it
> >>> fails on boot while executing one of the startup scripts:
> >>>
> >>> [    0.650000] STM32 USART driver initialized
> >>> [    0.650000] 40011000.serial: ttyS0 at MMIO 0x40011000 (irq = 17, 
> >>> base_baud = 5625000) is a stm32-usart
> >>> [    0.890000] console [ttyS0] enabled
> >>> [    0.910000] Freeing unused kernel memory: 12K (9000a000 - 9000d000) In
> >>> [    1.260000]
> >>> [    1.260000] Unhandled exception: IPSR = 00000003 LR = fffffff1
> >>> [    1.260000] CPU: 0 PID: 26 Comm: S20urandom Not tainted 4.5.0 #2
> >>> [    1.260000] Hardware name: STM32 (Device Tree Support)
> >>> [    1.260000] task: 90550000 ti: 9055a000 task.ti: 9055a000
> >>> [    1.260000] PC is at 0x21000000
> >>> [    1.260000] LR is at 0xfffffffd
> >>> [    1.260000] pc : [<21000000>]    lr : [<fffffffd>]    psr: 40000035
> >>> [    1.260000] sp : 9055bff8  ip : 9055bfe0  fp : 90555008
> >>> [    1.260000] r10: 00000000  r9 : 00000003  r8 : 00000024
> >>> [    1.260000] r7 : 00000072  r6 : 906ccad8  r5 : 00000000  r4 : 00000072
> >>> [    1.260000] r3 : 00000000  r2 : 00000003  r1 : 906ccafc  r0 : ffffffff
> >>> [    1.260000] xPSR: 40000035
> >>> [    1.260000] CPU: 0 PID: 26 Comm: S20urandom Not tainted 4.5.0 #2
> >>> [    1.260000] Hardware name: STM32 (Device Tree Support)
> >>> [    1.260000] [<0800bd41>] (unwind_backtrace) from [<0800b0df>] 
> >>> (show_stack+0xb/0xc)
> >>> [    1.260000] [<0800b0df>] (show_stack) from [<0800b68f>] 
> >>> (__invalid_entry+0x4b/0x4c)
> >>>
> >>> Without the patch the system boots up fine.
> >>
> >> Ok, thanks for the feedback.
> >>
> >> Can you try this patch instead then?
> >> It keeps the ARM.edix table at the same relative position, but moves
> >> the _etext symbol to be after the ARM.eidx table. The ARM.eidx section
> >> is marked as read-only in the linked ELF file.
> > 
> > This works for me.
> > What application is breaking without it?
> 
> Not a specific application. The problem I was trying to solve
> was for code compiled PIC. And specifically the case where the
> text and data sections where loading at non-contiguous RAM
> addresses. 
> 
> In the end problem is not so much this (this change only ended
> up added a ":text" to to the flatmem redirection of the segment
> contents). The problem actually seems to be related to code
> generation for symbols with hidden visibility - for the PIC
> case they where being loaded via PC relative instructions and
> not using register indirect via the designated base register.
> 
> Anyway, for now I don't think this patch is necessary, so you
> can ignore it.

Okay. Do you think disabling DOPIC in uClibc-ng is related to the
problem? Did you have DOPIC on or off for ypur ARM noMMU tests?

I have to disable it.

best regards
 Waldemar
_______________________________________________
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