Thanks very much for your sharing.
It's really good for me.
A question, please see below:
2008/12/8 Lin KJ <[EMAIL PROTECTED]>
> Hi all,
>
> According to my experience on exploring the toolchains for ARM uClinux, i
> got the following conclusions.
> 1) XIP uClinux
> - Both libgcc.a and libc.a must be compiled with XIP flags "-fpic
> -msingle-pic-base".
> - The "arm-linux" toolchains from uClinux website can NOT be used for
> XIP uClinux world.
> Because the libgcc.a is NOT compilied with the XIP flags.
> - The suitable toolchain for XIP uClinux is to rebuild it and hacked
> it by adding the XIP
> flags to FLAGS_FOR_TARGET.(on Makefile.in and Makefile.tpl)
>
Do you mean all steps (such as "build binutils", "build gcc stage1", "build
gcc stage2") when build toolchain should be hacked ?
or only the steps which generate "libgcc.a" and "libc.a" shoud be done that
?
> - The compiler version newer than gcc-4.x can NOT be used for XIP
> uClinux because of the
> "R_ARM_GOTOFF32" relocation type. It will produce the
> "R_ARM_GOTOFF32"
> relocation which will be resolved by adding a negative offset from
> the GOT. However,
> in the XIP uClinux, the GOT does not immediately follow the .text
> section, so a negative
> offset from the GOT expecting to find the .text section does not
> make any sense.
> For example:
> d6: 4803 ldr r0, [pc, #12] (e4 <.text+0xe4>)
> d8: 4450 add r0, sl
> ....
> e4: ffdc ffff undefined
> e4: R_ARM_GOTOFF32 .LC0
> - Following code can be used to test the "R_ARM_GOTOFF32" relocation
> type.
> void g(void (*h)(void)) {}
> static void f(void) { g(f); }
>
> 2) non-XIP uClinux
> - uClinux binaries do not necessarily have to be XIP.
> - Using the "arm-linux" toolchains under non-XIP, the wrapper linker
> has to be modofied to
> bypass the "-a" option to the elf2flt.
> - The "long long" variable division will cause the system failed.
>
> Above conclusions is based on my recent experience on ARM uClinux world.
> If i misunderstand something, please correct me.
>
> Best Regards,
> KJ
>
> ------------------------------
> *寄件者：* Arthur Wong <[EMAIL PROTECTED]>
> *收件者：* uClinux development list <uclinux-dev@uclinux.org>
> *寄件日期：* 2008/12/5(星期五) 上午10:50:09
>
> *主 旨：* Re: [uClinux-dev] Compiler library "libgcc.a" for uClinux
>
> It's a interesting discussion.
>
> After reading above, my understand is if i want to use XIP, i had do the
> following step:
>
> * rebuild arm-linux-toolchain, and make sure libgcc.a built with "-fpic
> -msingle-pic-base" .
> ( a question here: what about the other *.a, they should be built with the
> option too ? )
>
> * In uclinux distro, make sure the 3 config are commented.
>
> - # DISABLE_XIP := 1 # XIP works fine
> - # DISABLE_MOVE_RODATA := 1 # move-rodata is fine
> - # DISABLE_SHARED_LIBS := 1 # shared libs are fine
>
> What the other extra work should be done, does anybody can have a summary
> about "How to XIP in uClinux" ?
>
> Thanks very much.
>
> 2008/12/4 Lin KJ <[EMAIL PROTECTED]>
>
>> Hi Greg,
>>
>> Thanks for your help again.
>> It seems that there are some tricks on non-XIP uClinux.
>> To run the non-XIP uClinux, I omitted the "-fpic -msingle-pic-base" XIP
>> flags,
>> and specified the "DISABLE_XIP := 1", "DISABLE_MOVE_RODATA := 1" and
>> "DISABLE_SHARED_LIBS := 1" in the board-specific config.arch (someone
>> suggested in the mailing list).
>> After make clean and make, however, it is failed on the elf2flt stage.
>> I got the following repeated error messages.
>> "ERROR: reloc type R_ARM_PC24 unsupported in this context"
>> "ERROR: reloc type R_ARM_PLT32 unsupported in this context"
>>
>> Take a look to the elf2flt source code.
>> I found the "-a" FLTFLAGS was passed to elf2flt by wrapper
>> linker(/usr/local/arm-linux/bin/ld),
>> and elf2flt did the job by "use_resolved" mode.
>> For ARM, under that mode, the relocation type "R_ARM_PC24" and
>> "R_ARM_PLT32" can NOT be recognized.
>> By further checking, it is due to the piece code of wrapper linker.
>>
>> -----> if [ "yes" = "yes" ]
>> then
>> $LINKER $EMUL $SDIRS -T $LDSCRIPT -q -o "$OFILE.gdb"
>> $ARG1 ||exit $?
>> RFILE="$OFILE.gdb"
>> -----> FLTFLAGS="$FLTFLAGS -a"
>> else
>> if [ "yes" = "no" ]
>> then
>> $LINKER $EMUL $SDIRS -T $LDSCRIPT -Ur -d -o "$OFILE.elf"
>> $ARG1 ||exit $?
>> $LINKER $EMUL $SDIRS -T $LDSCRIPT -o "$OFILE.gdb"
>> $ARG1 ||exit $?
>> else
>> $LINKER $EMUL -r -d -o "$OFILE.elf2flt"
>> $ARG1 ||exit $?
>> $LINKER $EMUL $SDIRS -T $LDSCRIPT -Ur -o "$OFILE.elf"
>> "$OFILE.elf2flt" ||exit $?
>> $LINKER $EMUL $SDIRS -T $LDSCRIPT -o "$OFILE.gdb"
>> "$OFILE.elf2flt" ||exit $?
>> rm -f "$OFILE.elf2flt"
>> fi
>>
>> The wrapper linker always passes the "-a" option to the elf2flt and cause
>> the bad resolved relocation messages for R_ARM_PC24 and R_ARM_PLT32.
>> If i want to run the non-XIP uClinux, should i change the wrapper linker
>> code?
>> If yes, i should modify it to ["yes" = "no"] mode? or else mode?
>>
>> Best Regards,
>> KJ
>>
>>
>>
>>
>> ----- 原始信件 ----
>> 寄件者： Greg Ungerer <[EMAIL PROTECTED]>
>> 收件者： Lin KJ <[EMAIL PROTECTED]>
>> 副 本： uClinux development list <uclinux-dev@uclinux.org>
>> 寄件日期： 2008/12/4(星期四) 下午8:00:18
>> 主 旨： Re: [uClinux-dev] Compiler library "libgcc.a" for uClinux
>>
>>
>> Hi KJ,
>>
>> Lin KJ wrote:
>> > Thanks for your detailed information.
>> > But i am still puzzled.
>> > You mentioned that the uClinux binaries do not necessarily have to be
>> XIP and can be run on non-XIP mode.
>> > How do i switch to run non-XIP uClinux? Bypass the "-fpic
>> -msingle-pic-base" CFLAGS and use some specific elf2flt options?
>>
>> No magic from elf2flt required. Just omit those cflags.
>>
>>
>> > If uClinux could be non-XIP, why the "-fpic -msingle-pic-base" cflags
>> were added to the "uClinux-dist/vendors/config/armnommu/config.arch" file?
>>
>> When using the older arm-elf toolchain this was the default.
>> Now you will find that these are overriden in specific target
>> config.arch files.
>>
>>
>> > Actually, i am using the "arm-linux-tools-20070808.tar.gz" toolchain
>> downloaded from SnapGear.
>>
>> Yeah, that is what I use.
>>
>> Regards
>> Greg
>>
>>
>>
>> > ----- 原始信件 ----
>> > 寄件者： Greg Ungerer <[EMAIL PROTECTED]>
>> > 收件者： uClinux development list <uclinux-dev@uclinux.org>
>> > 寄件日期： 2008/12/4(星期四) 上午7:47:03
>> > 主 旨： Re: [uClinux-dev] Compiler library "libgcc.a" for uClinux
>> >
>> > Hi KJ,
>> >
>> > Lin KJ wrote:
>> >> I wonder whether the "arm-linux-" toolchains recommend by the uClinux
>> website can be used for ARM uClinux world.
>> >
>> > They can, I use them to create running systems.
>> > (I always test the GDB/ARMultaor uClinux target with those arm-linux
>> > toolchains).
>> >
>> >
>> >> The compiler library "libgcc.a" will be an issue.
>> >> Since XIP code is must for uClinux, the "libgcc.a" must be produced by
>> the XIP compiling flags.
>> >
>> > No, that is not the case. uClinux binaries do not necessarily have
>> > to be XIP. For the FLAT format using targets elf2flt can create
>> > binaries that do full relocation at load/run time.
>> >
>> > And this is the case I normally use. For the XIP cases you
>> > won't have the right libgcc.a from those toolchains. You would
>> > need to generate a toolchain from source and multilib it
>> > for the XIP case you want.
>> >
>> >
>> >> For ARM, it will be "-fpic -msingle-pic-base".
>> >> By objdump inspecting, I found the libgcc.a of the "arm-linux"
>> toolchains on the uClinux website is not compilied by the options.
>> >
>> > Thats right...
>> >
>> >
>> >> When the program calls the functions of libgcc.a, it will be broken in
>> some cases.
>> >> The easy way to test is to do the "long long" variable division.
>> >> However, i seldom heard people complain about their toolchains.
>> >> Why? Or my understanding is wrong?
>> >
>> > The arm-linux toolchain is really a standard VM linux tool chain.
>> > It also happens to work for the non-XIP uClinux case, which is why
>> > I use it. (One toolchain for all the arm-linux work I do).
>> >
>> >
>> >> Doesn't other architecture have the same issue?
>> >
>> > It all depends on the toolchain in this case. Unfortunately there
>> > is a lot of different binary packages out there (different versions,
>> > different patches applied, etc). Some won't compile older uClinux-dist,
>> > some won't compile newer, it is a trick to find a combination that
>> > works the way you want it to (at least if you don't want to build
>> > the toolchain yourself).
>> >
>> > Regards
>> > Greg
>> >
>> >
>> > ------------------------------------------------------------------------
>> > Greg Ungerer -- Principal Engineer EMAIL: [EMAIL PROTECTED]
>> > SnapGear, a McAfee Company PHONE: +61 7 3435 2888
>> > 825 Stanley St, FAX: +61 7 3891 3630
>> > Woolloongabba, QLD, 4102, Australia WEB:
>> > http://www.SnapGear.com<http://www.snapgear.com/>
>> > _______________________________________________
>> > 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
>> >
>> >
>> >
>> >
>> ______________________________________________________________________________________________________
>> > 付費才容量無上限？Yahoo!奇摩電子信箱2.0免費給你，信件永遠不必刪！
>> http://tw.mg0.mail.yahoo.com/dc/landing
>> >
>> >
>>
>>
>> --
>> ------------------------------------------------------------------------
>> Greg Ungerer -- Principal Engineer EMAIL: [EMAIL PROTECTED]
>> SnapGear, a McAfee Company PHONE: +61 7 3435 2888
>> 825 Stanley St, FAX: +61 7 3891 3630
>> Woolloongabba, QLD, 4102, Australia WEB:
>> http://www.SnapGear.com<http://www.snapgear.com/>
>>
>>
>>
>>
>>
>> ______________________________________________________________________________________________________
>> 付費才容量無上限？Yahoo!奇摩電子信箱2.0免費給你，信件永遠不必刪！
>> http://tw.mg0.mail.yahoo.com/dc/landing
>> _______________________________________________
>> 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
>>
>
>
> 付費才容量無上限？Yahoo!奇摩電子信箱2.0免費給你，信件永遠不必刪！ -
> *馬上體驗*<http://tw.rd.yahoo.com/referurl/mail/mail20/tag_hot0103/*http://tw.mg0.mail.yahoo.com/dc/landing>
> ！
>
> _______________________________________________
> 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
>
_______________________________________________
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
