Hi
ok no more SIGSEGV but with:
static long global_right_encoder;
static double VitR;
int init_module(void)
{
VitR = (double)global_right_encoder;
return 0;
}
insmod ucAsserv.o
Using ucAsserv.o
insmod: unresolved symbol __floatsidf
After the module was unloaded !
the compile line is now:
/opt/uClinux-m68k-elf/bin/m68k-elf-gcc -iwithprefix include
-DKBUILD_BASENAME=ucAsserv -fno-builtin -nostdinc -O2
-fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -D__ELF__
-DMAGIC_ROM_PTR -DNO_FORGET -DUTS_SYSNAME="uClinux" -DNO_MM -DNO_FPU
-DNO_CACHE -DNO_CACHE -DMODULE -D__KERNEL__ -isystem
../uClinux-dist-20060803/linux-2.4.x/include -m68000 -Dlinux
-D__linux__ -Dunix -D__uClinux__ -DEMBED -c -o ucAsserv.o ucAsserv.c
the cpu is
MC68vz328
thanks
stephane Germain
Greg Ungerer a écrit :
> Hi Stephane,
>
> Stéphane wrote:
>> In Makefile:
>>
>> /********************/
>>
>> INCLUDE := -isystem ../uClinux-dist-20060803/linux-2.4.x/include
>> CFLAGS := -DMODULE -D__KERNEL__ ${WARN} ${INCLUDE}
>> CC := /opt/uClinux-m68k-elf/bin/m68k-elf-gcc
>> ${TARGET}.o: ${TARGET}.c
>
> What CPU are you running on?
> What is the actual compile line?
>
> From the ensuing discussion I would guess that you are not
> compiling with the appropriate CPU class passed to gcc.
>
> If you are using a ColdFire you should at least have an
> -m5200 (or equivalent) gcc option. If a base 68k (like
> 68328 or similar) then -m68000. Otherwise you won't get
> instructions generated appropriate to your CPU.
>
> Regards
> Greg
>
>
>
>> /************************/
>>
>> and with -S :
>>
>> /*****************************************/
>>
>> .file "ucAsserv.c"
>> gcc2_compiled.:
>> .section .modinfo,"a",@progbits
>> .type __module_kernel_version,@object
>> .size __module_kernel_version,33
>> __module_kernel_version:
>> .string "kernel_version=2.4.31-uc0-ANI-10"
>> .section .rodata
>> .LC0:
>> .string "<6>Bug:\n"
>> .LC1:
>> .string "<6>Never Reach\n"
>> .text
>> .align 2
>> .globl init_module
>> .type init_module,@function
>> init_module:
>> link.w %a6,#0
>> clr.l VitL
>> clr.l global_left_encoder
>> clr.l global_right_encoder
>> pea .LC0
>> jsr printk
>> addq.l #4,%sp
>> move.l global_left_encoder,%d0
>> muls.l global_right_encoder,%d0
>> move.l %d0,VitL
>> pea .LC1
>> jsr printk
>> addq.l #4,%sp
>> clr.l %d0
>> jbra .L95
>> .align 2
>> .L95:
>> unlk %a6
>> rts
>> .Lfe1:
>> .size init_module,.Lfe1-init_module
>> .align 2
>> .globl cleanup_module
>> .type cleanup_module,@function
>> cleanup_module:
>> link.w %a6,#0
>> .L96:
>> unlk %a6
>> rts
>> .Lfe2:
>> .size cleanup_module,.Lfe2-cleanup_module
>> .globl __module_author
>> .section .modinfo
>> .type __module_author,@object
>> .size __module_author,24
>> __module_author:
>> .string "author=Stephane Germain"
>> .type __module_license,@object
>> .size __module_license,12
>> __module_license:
>> .string "license=GPL"
>> .local global_right_encoder
>> .comm global_right_encoder,4,2
>> .local global_left_encoder
>> .comm global_left_encoder,4,2
>> .local VitL
>> .comm VitL,4,2
>> .ident "GCC: (GNU) 2.95.3 20010315 (release)(ColdFire patches -
>> 20010318 from
>> http://fiddes.net/coldfire/)(uClinux XIP and shared lib patches from
>> http://www.snapgear.com/)"
>>
>> /***************************************************/
>>
>>
>> I use the default toolchain
>>
>> /opt/uClinux-m68k-elf/bin/m68k-elf-gcc -v :
>> Reading specs from
>> /opt/uClinux-m68k-elf/lib/gcc-lib/m68k-elf/2.95.3/specs
>> gcc version 2.95.3 20010315 (release)(ColdFire patches - 20010318 from
>> http://fiddes.net/coldfire/)(uClinux XIP
>> and shared lib patches from http://www.snapgear.com/)
>>
>> thanks
>>
>>
>> Wolfgang Reissnegger a écrit :
>>> Hi Stéphane,
>>>
>>> looks like you are compiling your code with compiler flags that
>>> generate instructions that the processor does not support. That's why
>>> you see the illegal instruction trap.
>>>
>>> The reason that it all works if the variables are local is probably
>>> that you also use an optimization flag (e.g. -O3) that causes the
>>> compiler to optimize the whole multiplication away in main because it
>>> has no effect on the function's result and is local to the function.
>>>
>>> You should try to compile the code with gcc -S to generate assembler
>>> output. Then you can identify the instruction that causes the problem.
>>>
>>> Cheers,
>>> Wolfgang
>>>
>>> Stéphane wrote:
>>>> Hi,
>>>>
>>>> I have a bug that I can be resume as:
>>>>
>>>> /***************************/
>>>> #include <linux/module.h> // Needed by all modules
>>>> #include <linux/kernel.h> // Needed for KERN_INFO
>>>>
>>>> static long global_right_encoder;
>>>> static long global_left_encoder;
>>>> static long VitL;
>>>>
>>>> int init_module(void)
>>>> {
>>>> VitL = 0;
>>>> global_left_encoder = 0;
>>>> global_right_encoder = 0;
>>>>
>>>> printk(KERN_INFO "Bug:\n");
>>>> VitL = global_left_encoder*global_right_encoder;
>>>> printk(KERN_INFO "Never Reach\n");
>>>> return 0;
>>>> }
>>>>
>>>>
>>>> void cleanup_module(void)
>>>> {
>>>> }
>>>>
>>>> MODULE_AUTHOR("Stephane Germain");
>>>> MODULE_LICENSE("GPL");
>>>> /**********************************/
>>>>
>>>> result:
>>>>
>>>> insmod xxx.o:
>>>> SIGSEGV
>>>>
>>>> dmesg:
>>>> Bug:
>>>> *** ILLEGAL INSTRUCTION *** FORMAT=0
>>>> Current process id is 47
>>>> BAD KERNEL TRAP: 00000000
>>>> PC: [<000a8bec>]
>>>> SR: 2014 SP: 007dbee8 a2: 10c16b34
>>>> d0: 00000000 d1: 00000991 d2: 00000000 d3: ffffffea
>>>> d4: 00000060 d5: 00000008 a0: 0003dc8c a1: 0003dca8
>>>> Process insmod (pid: 47, stackpage=007db000)
>>>> Frame format=0
>>>> Stack from 007dbf1c:
>>>> 000a8c14 007d3000 007dbfc4 10c17856 007c5348 00102428 007c5348
>>>> 000000e8
>>>> 00000002 00000001 007da000 00192e00 007c51c0 00190004 00140560
>>>> 0015fae0
>>>> 007d3000 007d4000 00000060 0003dd58 000a8bc0 000000e8 00000000
>>>> 00000000
>>>> 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>>>> 00000000
>>>> 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>>>> 00000000
>>>> 00000000 00000000 0019fdc8 10c127d2 00192e00 007c5348 00102428
>>>> 007c5348
>>>> Call Trace:
>>>> [<10c17856>] [<10c127d2>]
>>>> Code: 4c39 0800 000a 8c3c 23c0 000a 8c44 4879 000a 8c1d
>>>>
>>>> /*****************************/
>>>>
>>>>
>>>> if the variables are local, all work!
>>>>
>>>> Somebody know something that I don't about that?
>>>>
>>>> Thanks
>>>>
>>>> Stephane Germain
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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
