H i Greg,
I tried to compile the uClinux-dist(20080808)/user/flthdr as my testing.
And i got the following error messages.
# make user_only
....
....
make[3]: Entering directory `/home/kjlin/tmp/new/uClinux-dist/user/flthdr'
ucfront-gcc arm-linux-gcc -Os -g -fomit-frame-pointer
-pipe -msoft-float -fno-common -fno-builtin -Wall -DEMBED -Dlinux -D__linux__
-Dunix -D__uClinux__ -c -o flthdr.o flthdr.c
flthdr.c:44: warning: short_format defined but not used
ucfront-gcc arm-linux-gcc -Wl,-elf2flt -msoft-float -Wl,-elf2flt -msoft-float
-o flthdr flthdr.o
ERROR: reloc type R_ARM_PC24 unsupported in this context
ERROR: reloc type R_ARM_PC24 unsupported in this context
...
...
ERROR: reloc type R_ARM_PLT32 unsupported in this context
ERROR: reloc type R_ARM_PLT32 unsupported in this context
ERROR: reloc type R_ARM_PLT32 unsupported in this context
ERROR: reloc type R_ARM_PC24 unsupported in this context
...
...
ERROR: reloc type R_ARM_PC24 unsupported in this context
470 bad relocs
collect2: ld returned 1 exit status
Once i modified the wrapper linker code to bypass the elf2flt "-a" flag
mentioned last discussion,
the building process was fine.
I wonder if the default wrapper linker of "arm-linux" toolchain can be used for
non-XIP uClinux.
By the way, have you ever tested the "long long" variable division under
non-XIP mode?
I tried the following code:
#include <stdio.h>
void main(void)
{
long long a,b;
a=100;b=3;
printf("res: %d\n",a/b);
}
It will cause the "Illegal instruction" error while executing.
Listed its symbols by "arm-linux-nm test.gdb" and found that the
"_GLOBAL_OFFSET_TABLE_" was one of the symbols.
It should NOT be there and I think it is the reason that "Illegal instruction"
happened.
However, when i change the "long long" to "long" variable everything is fine.
Nor more "_GLOBAL_OFFSET_TABLE_" is in the symbols list and executed correctly.
Regards,
KJ
----- 原始信件 ----
寄件者： Greg Ungerer <[EMAIL PROTECTED]>
收件者： Lin KJ <[EMAIL PROTECTED]>
副 本： uclinux-dev@uclinux.org
寄件日期： 2008/12/5(星期五) 下午1:24:03
主 旨： Re: [uClinux-dev] Compiler library "libgcc.a" for uClinux
> 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
______________________________________________________________________________________________________
付費才容量無上限？Yahoo!奇摩電子信箱2.0免費給你，信件永遠不必刪！ http://tw.mg0.mail.yahoo.com/dc/landing
______________________________________________________________________________________________________
付費才容量無上限？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
