future merge

Tue Jun 28 07:30:26 UTC 2011

On 27/06/2011 21.53, Khem Raj wrote:
> On Mon, Jun 27, 2011 at 8:01 AM, Carmelo AMOROSO <carmelo.amoroso at st.com> wrote:
>> On 27/06/2011 10.25, Carmelo AMOROSO wrote:
>>> On 24/06/2011 16.37, Carmelo AMOROSO wrote:
>>>> On 13/06/2011 22.17, Khem Raj wrote:
>>>>> On Mon, Jun 13, 2011 at 12:40 PM, Carmelo AMOROSO
>>>>> <carmelo.amoroso at st.com> wrote:
>>>>>> On 08/06/2011 23.22, Khem Raj wrote:
>>>>>>> On Wed, Jun 8, 2011 at 2:17 PM, Bernhard Reutner-Fischer
>>>>>>> <rep.dot.nop at gmail.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> master is now potentially open to
>>>>>>>> - merge future into master
>>>>>>>> - merge prelink into master
>>>>>>>> - merge ldso-future into master
>>>>>>>> (in this order).
>>>>>>>>
>>>>>>>> To do this, ideally one would bring future up to date, then merge it
>>>>>>>> back into master etc.
>>>>>>>>
>>>>>>>> Peter, do you see fit to
>>>>>>>> $ git checkout future
>>>>>>>> $ git pull --rebase (provided future is a proper tracking branch)
>>>>>>>> $ git push -v
>>>>>>>> $ git checkout master
>>>>>>>> $ git merge origin/future
>>>>>>>> # edit
>>>>>>>> $ git add some/thing
>>>>>>>> $ git commit -s some/thing
>>>>>>>> etc, etc?
>>>>>>>>
>>>>>>>> Current future would most likely conflict in e.g. longjmp impl i.e.
>>>>>>>> would need to be resolved after such merge (and i didn't look, TBH).
>>>>>>>>
>>>>>>>> Any takers? Khem, do you have time to explain and resolve that with
>>>>>>>> peter? Anybody else?
>>>>>>>
>>>>>>> I can merge the future branch into master carefully
>>>>>>> and also some patches that are on hold.
>>>>>>>
>>>>>>> Carmelo
>>>>>>>
>>>>>>> I think prelink branch should probably be merged in first.
>>>>>>>
>>>>>>> Thanks
>>>>>>> -Khem
>>>>>>
>>>>>> Hi guys,
>>>>>> sorry I was off from uClibc dev for a while... yes I'd prefer to merge
>>>>>> prelink before, because it's just touch ldso stuff.
>>>>>>
>>>>>> Prelink has been merge with master multiple times, so it is almost
>>>>>> up-to-date. I'll re-merge again, and if you agree, I can merge it back
>>>>>> to master.
>>>>>>
>>>>>
>>>>> Carmelo
>>>>>
>>>>> Yes thats my preference too. So please go ahead and I will wait
>>>>>
>>>>
>>>> Hi,
>>>> I've merge prelink with master, solved few conflicts and tested.
>>>> I'm going to push prelink. Then I'll take care of merging it back to master.
>>>>
>>>> ok to proceed ?
>>>>
>>>> Cheers,
>>>> Carmelo
>>>>
>>>
>>
>> Hi,
>>
>>> I've merged it and booted on SH4 board. Run C lib suite and prelink
>>> suite without regression.
>>>
>>
>> this the output on the target, showing the stand-alone mode capability.
>>
>> root at amorosoc:~# /lib/ld-uClibc.so.0
>> Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
>> You have invoked `ld.so', the helper program for shared library executables.
>> This program usually lives in the file `/lib/ld.so', and special directives
>> in executable files using ELF shared libraries tell the system's program
>> loader to load the helper program from this file.  This helper program loads
>> the shared libraries needed by the program executable, prepares the program
>> to run, and runs it.  You may invoke this helper program directly from the
>> command line to load and run an ELF executable file; this is like executing
>> that file itself, but always uses this helper program from the file you
>> specified, instead of the helper program file specified in the executable
>> file you run.  This is mostly of use for maintainers to test new versions
>> of this helper program; chances are you did not intend to run this program.
>>
>>  --library-path PATH   use given PATH instead of content of the environment
>>                        variable LD_LIBRARY_PATH
>> root at amorosoc:~#
>> root at amorosoc:~#
>> root at amorosoc:~# /lib/ld-uClibc.so.0 /bin/cat /proc/cpuinfo
>> machine         : hdk7106
>> processor       : 0
>> cpu family      : sh4
>> cpu type        : STx7106
>> cut             : 1.x
>> cpu flags       : fpu icbi synco fpchg
>> cache type      : split (harvard)
>> icache size     : 32KiB (2-way)
>> dcache size     : 32KiB (2-way)
>> address sizes   : 32 bits physical
>> bogomips        : 450.00
>>
>>
>>
>>> Now testing on ARM CA9 (and probably on ARM9 if I get a booting kernel)
>>> and let you now.
>>>
>>
>> I've successfully booted a ARM CA9 core, and this is some outputs:
>>
>> ------------
>> root at amorosoc:~# /lib/ld-uClibc.so.0
>> Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
>> You have invoked `ld.so', the helper program for shared library executables.
>> This program usually lives in the file `/lib/ld.so', and special directives
>> in executable files using ELF shared libraries tell the system's program
>> loader to load the helper program from this file.  This helper program loads
>> the shared libraries needed by the program executable, prepares the program
>> to run, and runs it.  You may invoke this helper program directly from the
>> command line to load and run an ELF executable file; this is like executing
>> that file itself, but always uses this helper program from the file you
>> specified, instead of the helper program file specified in the executable
>> file you run.  This is mostly of use for maintainers to test new versions
>> of this helper program; chances are you did not intend to run this program.
>>
>>  --library-path PATH   use given PATH instead of content of the environment
>>                        variable LD_LIBRARY_PATH
>> root at amorosoc:~#
>> root at amorosoc:~#
>> root at amorosoc:~# /lib/ld-uClibc.so.0 /bin/cat /proc/cpuinfo
>> machine         : hdk7106
>> processor       : 0
>> cpu family      : sh4
>> cpu type        : STx7106
>> cut             : 1.x
>> cpu flags       : fpu icbi synco fpchg
>> cache type      : split (harvard)
>> icache size     : 32KiB (2-way)
>> dcache size     : 32KiB (2-way)
>> address sizes   : 32 bits physical
>> bogomips        : 450.00
>> ----------------------
>>
>> I've got some problem on few tests referencing h_errno due to
>> unsupported ARM relocations. This is due to the version of binutils I'm
>> using (indeed I get the same errors on a vanilla master branch).
>>
>> I'll work to the ARM ld.so to include this support also.
>>
>> I think we are in the position to push it now. If you guys prefer to
>> have a look before I push, I can create a temporary branch. Let me know.
> 
> If you want to get the patches a final look then its ok. I am ok with pushing
> it as it is. Since I will then test it on mips ppc and x86 soon after and any
> breakage can be figured out.
> 

Hi khem,
yes indeed I've liked that others have had a look at the prelink changes
due to the huge impact on the ld.so,
so I've pushed a branch 'integration/prelink_on_master' on ST git.

http://git.stlinux.com/?p=stm/uclibc.git;a=shortlog;h=integration/prelink_on_master

git clone git://git.stlinux.com/stm/uclibc.git integration/prelink_on_master

I'll hold on other few days for other feedback, and then I'll push.

Thanks,
Carmelo