The compiler libraries (in stage 2) have to be compilied with XIP flags(-fpic
-msingle-pic-base).
The libc.a has also to be compilied with the XIP flags, but it is not the part
of building process of compiler.
________________________________
寄件者： Arthur Wong <[EMAIL PROTECTED]>
收件者： uClinux development list <uclinux-dev@uclinux.org>
寄件日期： 2008/12/8(星期一) 下午4:43:04
主 旨： Re: [uClinux-dev] Compiler library "libgcc.a" for uClinux
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 fineWhat 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
> _______________________________________________
> 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
______________________________________________________________________________________________________
付費才容量無上限？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免費給你，信件永遠不必刪！ - 馬上體驗！
_______________________________________________
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_______________________________________________
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
