Hi KJ,
Lin KJ wrote:
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).
You should only need to do this. That will not use the "-fpic
-msingle-pic-base" flags after that.
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"
Can you give the exact link line and exact error output?
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?
I dunno, I wouldn't have expected that you needed to do any
more.
Regards
Greg
----- 原始信件 ----
寄件者： 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
--
------------------------------------------------------------------------
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
