Re: [PATCH v2] allow to build arm flat binaries

Hi Waldemar,

On 27/08/16 21:25, Waldemar Brodkorb wrote:
> 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 <[email protected]>
>>>>>>>
>>>>>>> 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.

Yes, I have to disable it too. Having DOPIC on will compile the
lib code with -fPIC - and that is where I see some problems.
Not sure of the root of those problems yet, but you get access
being attempted outside of the text and data when they are loaded
in separate memory regions.

Regards
Greg


_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev