From meloun at miracle.cz Mon Nov 3 09:58:49 2008 From: meloun at miracle.cz (Meloun Michal) Date: Mon, 03 Nov 2008 10:58:49 +0100 Subject: Bug in 2008Q3 release Message-ID: <490ECB5A.18100.D9F2385@meloun.miracle.cz> Hello everybody! Unfortunately, I have problem with 2008Q3 release. GCC miscompile this small test case. //----------------------------------------------------------------- //m68k-elf-gcc -mcpu=5470 -save-temps -da -c test.c -o test.o int Test2(char*); static void Test3(void) { char tmp2[2] = "0"; } void Test4(void) { Test2("0"); } //------------------------------------------------------------------ The file is compiled to: #NO_APP .file "test.c" .section .rodata .LC0: .string "0" .text .align 2 .type Test3, @function Test3: link.w %fp,#-4 lea .LC0,%a0 ; <<-- !!!! Note: a0 contain ptr to "0" here move.w (%a0),-2(%fp) unlk %fp rts .size Test3, .-Test3 .align 2 .globl Test4 .type Test4, @function Test4: link.w %fp,#0 move.l %a0,-(%sp) ; <<-- !!!! a0 is used uninitialized here jsr Test2 addq.l #4,%sp unlk %fp rts .size Test4, .-Test4 .ident "GCC: (GNU) 4.3.2" And relevant part of RTL: (please note missing reference to string constatnt "0" in first insn. ;; Function Test4 (Test4) ;; Generating RTL for tree basic block 2 ;; Test2 (&"0"[0]) (insn 5 4 6 test.c:11 (set (mem/f/i:SI (pre_dec:SI (reg/f:SI 15 %sp)) [0 S4 A16]) (reg:SI 8 %a0)) -1 (nil)) <<-- !!!! Why a0 ???? (call_insn 6 5 7 test.c:11 (set (reg:SI 0 %d0) (call (mem:QI (symbol_ref:SI ("Test2") [flags 0x41] ) [0 S1 A8]) (const_int 4 [0x4]))) -1 (nil) (nil)) (insn 7 6 0 test.c:11 (set (reg/f:SI 15 %sp) (plus:SI (reg/f:SI 15 %sp) (const_int 4 [0x4]))) -1 (nil)) But, if i change one of strings "0" to something else, then first insn have reference to string and code is compiled OK. RTL: ;; Test2 (&"1"[0]) (insn 5 4 6 test.c:11 (set (mem/f/i:SI (pre_dec:SI (reg/f:SI 15 %sp)) [0 S4 A16]) (symbol_ref/f:SI ("*.LC1") [flags 0x2] )) -1 (nil)) code: Test4: link.w %fp,#0 pea .LC1 jsr Test2 addq.l #4,%sp unlk %fp rts For me, its looks like compiler forget reinitialize (clear) registers content (assignment) between functions and uses a0 assigned in function Test3. Unfortunately, I m not gcc expert and fixing this problem is out of my knowledge. Can anybody help me, please? Btw, vanilla gcc 4.3.2 have exactly same problem (and some other - in long long expansions). Many thanks Michal Meloun From maxim at codesourcery.com Mon Nov 3 11:28:49 2008 From: maxim at codesourcery.com (Maxim Kuvyrkov) Date: Mon, 03 Nov 2008 12:28:49 +0100 Subject: [coldfire-gnu-discuss] Bug in 2008Q3 release In-Reply-To: <490ECB5A.18100.D9F2385@meloun.miracle.cz> References: <490ECB5A.18100.D9F2385@meloun.miracle.cz> Message-ID: <490EE071.8060706@codesourcery.com> Meloun Michal wrote: > Hello everybody! > Unfortunately, I have problem with 2008Q3 release. > GCC miscompile this small test case. Hello Meloun, Thank you for the bug report, we will investigate this. -- Maxim Kuvyrkov CodeSourcery From meloun at miracle.cz Sun Nov 2 12:31:38 2008 From: meloun at miracle.cz (Meloun Michal) Date: Sun, 02 Nov 2008 13:31:38 +0100 Subject: Bug in 2008Q3 release Message-ID: <490D9DAB.10895.904A761@meloun.miracle.cz> Hello everybody! Unfortunately, I have problem with 2008Q3 release. GCC miscompile this small test case. //----------------------------------------------------------------- //m68k-elf-gcc -mcpu=5470 -save-temps -da -c test.c -o test.o int Test2(char*); static void Test3(void) { char tmp2[2] = "0"; } void Test4(void) { Test2("0"); } //------------------------------------------------------------------ The file is compiled to: #NO_APP .file "test.c" .section .rodata .LC0: .string "0" .text .align 2 .type Test3, @function Test3: link.w %fp,#-4 lea .LC0,%a0 ; <<-- !!!! Note: a0 contain ptr to "0" here move.w (%a0),-2(%fp) unlk %fp rts .size Test3, .-Test3 .align 2 .globl Test4 .type Test4, @function Test4: link.w %fp,#0 move.l %a0,-(%sp) ; <<-- !!!! a0 is used uninitialized here jsr Test2 addq.l #4,%sp unlk %fp rts .size Test4, .-Test4 .ident "GCC: (GNU) 4.3.2" And relevant part of RTL: (please note missing reference to string constatnt "0" in first insn. ;; Function Test4 (Test4) ;; Generating RTL for tree basic block 2 ;; Test2 (&"0"[0]) (insn 5 4 6 test.c:11 (set (mem/f/i:SI (pre_dec:SI (reg/f:SI 15 %sp)) [0 S4 A16]) (reg:SI 8 %a0)) -1 (nil)) <<-- !!!! Why a0 ???? (call_insn 6 5 7 test.c:11 (set (reg:SI 0 %d0) (call (mem:QI (symbol_ref:SI ("Test2") [flags 0x41] ) [0 S1 A8]) (const_int 4 [0x4]))) -1 (nil) (nil)) (insn 7 6 0 test.c:11 (set (reg/f:SI 15 %sp) (plus:SI (reg/f:SI 15 %sp) (const_int 4 [0x4]))) -1 (nil)) But, if i change one of strings "0" to something else, then first insn have reference to string and code is compiled OK. RTL: ;; Test2 (&"1"[0]) (insn 5 4 6 test.c:11 (set (mem/f/i:SI (pre_dec:SI (reg/f:SI 15 %sp)) [0 S4 A16]) (symbol_ref/f:SI ("*.LC1") [flags 0x2] )) -1 (nil)) code: Test4: link.w %fp,#0 pea .LC1 jsr Test2 addq.l #4,%sp unlk %fp rts For me, its looks like compiler forget reinitialize (clear) registers content (assignment) between functions and uses a0 assigned in function Test3. Unfortunately, I m not gcc expert and this problem is out of my knowledge. Can anybody help me, please? Btw, vanilla gcc 4.3.2 have exactly same problem (and some other - in long long expansions). Many thanks Michal Meloun From Corrin.Meyer at dornerworks.com Fri Nov 7 22:16:15 2008 From: Corrin.Meyer at dornerworks.com (Corrin Meyer) Date: Fri, 7 Nov 2008 17:16:15 -0500 Subject: Link Duplicate Input Section? Message-ID: I need to be able to take link input section and place it in an output section in two different locations. Something like the following... SECTIONS { .text : { *(.vector_table); . = 0x3000; *(.vector_table); *(.text .text.*); } >rom } Note how I am trying to place *(.vector_table) in the output at both 0x0 and 0x3000 inside the rom section. I tried this and it doesn't seem to work. The output only contains the first *(.vector_table). Corrin J. Meyer? DornerWorks, Ltd. Embedded Systems Engineering ? T: 616.389.8336 F: 616.245.8372 E: corrin.meyer at dornerworks.com? ?? 3445 Lake Eastbrook Blvd. SE? Grand Rapids, MI 49546 From Corrin.Meyer at dornerworks.com Sat Nov 8 00:13:03 2008 From: Corrin.Meyer at dornerworks.com (Corrin Meyer) Date: Fri, 7 Nov 2008 19:13:03 -0500 Subject: RAMBAR0 incorrectly set by __cs3_reset Message-ID: I have started to experience a boot failure issue and I think I have tracked it down to __cs3_reset. The boot failure is resulting in an access error and it appears that it is because that RAMBAR0 (FLASHBAR) is being incorrectly set by the CS3 reset function __cs3_reset. Below are two versions of __cs3_reset as results from a compile that works and a compile that doesn't. The processor I am working with is a MCF52235. This does work... 3400: 223c 2000 0021 movel #536870945,%d1 3406: 4e7b 1c05 movec %d1,%rambar1 340a: 223c 0000 0021 movel #33,%d1 3410: 4e7b 1c04 movec %d1,%rambar0 3414: 700f moveq #15,%d0 3416: 13c0 4010 0074 moveb %d0,40100074 <__cs3_region_start_ipsbar+0x100074> 341c: 4ef9 0001 be30 jmp 1be30 <_start> This does not work... 3400: 223c 2000 0021 movel #536870945,%d1 3406: 4e7b 1c05 movec %d1,%rambar1 340a: 223c 0000 3021 movel #12321,%d1 3410: 4e7b 1c04 movec %d1,%rambar0 3414: 700f moveq #15,%d0 3416: 13c0 4010 0074 moveb %d0,40100074 <__cs3_region_start_ipsbar+0x100074> 341c: 4ef9 0001 be30 jmp 1be30 <_start> It appears that in the working case 0x00000021 is being loaded in RAMBAR0 and in the non-working case it is being loaded with 0x00003021. The value 0x00003021 is setting bits in RAMBAR0 (FLASHBAR) that are reserved and I believe it to be these bits (0x00003000) that are causing my problems; using GDB and stepping through code I was able to examine Flash memory correctly prior to setting RAMBAR0. Once RAMBAR0 was set, accessing the same memory locations resulted in corrupted data. How is the value that is being loaded into RAMBAR0 being determined? Is there anyway that I can control what that value is without having to replace the __cs3_reset (or maybe there is an easy way to override just the __cs3_reset code without having to replace all of CS3)? Corrin J. Meyer DornerWorks, Ltd. Embedded Systems Engineering T: 616.389.8336 F: 616.245.8372 E: corrin.meyer at dornerworks.com 3445 Lake Eastbrook Blvd. SE Grand Rapids, MI 49546 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan at codesourcery.com Sat Nov 8 10:10:52 2008 From: nathan at codesourcery.com (Nathan Sidwell) Date: Sat, 08 Nov 2008 10:10:52 +0000 Subject: [coldfire-gnu-discuss] RAMBAR0 incorrectly set by __cs3_reset In-Reply-To: References: Message-ID: <491565AC.8060203@codesourcery.com> Corrin Meyer wrote: > I have started to experience a boot failure issue and I think I have > tracked it down to __cs3_reset. The boot failure is resulting in an > access error and it appears that it is because that RAMBAR0 (FLASHBAR) > is being incorrectly set by the CS3 reset function __cs3_reset. Below > are two versions of __cs3_reset as results from a compile that works and > a compile that doesn?t. The processor I am working with is a MCF52235. Which 52235 board are you targeting? How are you linking your program? Are you using a modified linker script? > It appears that in the working case 0x00000021 is being loaded in > RAMBAR0 and in the non-working case it is being loaded with 0x00003021. > How is the value that is being loaded into RAMBAR0 being determined? It is the value of the __cs3_region_start_rom plus 0x21. __cs3_region_start_rom should be zero. Can you determine if that is the case, and if not why not? > Is > there anyway that I can control what that value is without having to > replace the __cs3_reset (or maybe there is an easy way to override just > the __cs3_reset code without having to replace all of CS3)? Yes, provide your own implementation of the routine in a .cs3.reset section. Provide a global symbol __cs3_reset_cobra52235 (adjust if you're not using the cobra52235 board), and make sure it ends with a jump to _start. This is documented in the getting started guide. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery From Corrin.Meyer at dornerworks.com Sat Nov 8 17:50:50 2008 From: Corrin.Meyer at dornerworks.com (Corrin Meyer) Date: Sat, 8 Nov 2008 12:50:50 -0500 Subject: [coldfire-gnu-discuss] RAMBAR0 incorrectly set by __cs3_reset In-Reply-To: <491565AC.8060203@codesourcery.com> References: <491565AC.8060203@codesourcery.com> Message-ID: > Which 52235 board are you targeting? > How are you linking your program? > Are you using a modified linker script? I am using a modified linker script targeting a custom board that should look like the M52235EVB. > It is the value of the __cs3_region_start_rom plus 0x21. > __cs3_region_start_rom should be zero. Can you determine if that is the > case, > and if not why not? It appears that __cs3_region_start_rom is not being set to 0 and it is because of my modified linker script. I had changed the flash origin to 0x00003000 because I have a bootloader that resides at 0x0 which does all the pre-configuring. Knowing that __cs3_region_start_rom needs to be 0x0 I should be able to modify my linker script accordingly. > Yes, provide your own implementation of the routine in a .cs3.reset > section. > Provide a global symbol __cs3_reset_cobra52235 (adjust if you're not using > the > cobra52235 board), and make sure it ends with a jump to _start. This is > documented in the getting started guide. Cool. Thanks for the pointer. Corrin J. Meyer DornerWorks, Ltd. Embedded Systems Engineering T: 616.389.8336 F: 616.245.8372 E: corrin.meyer at dornerworks.com 3445 Lake Eastbrook Blvd. SE Grand Rapids, MI 49546 From dave at meadorresearch.com Wed Nov 12 06:34:18 2008 From: dave at meadorresearch.com (Dave Meador) Date: Tue, 11 Nov 2008 22:34:18 -0800 Subject: Coldfire uclinux problem Message-ID: <491A78EA.4010205@meadorresearch.com> Hello, I tried to compile uclinux-dist-20080808 with uClinux-dist-20080808-20080922.patch applied and with Freescale,M5475EVB selected. I am using version Sourcery G++ Lite 4.3-45 compiler. All files compile, but the linker fails with the following linker error: LD init/built-in.o LD vmlinux /opt/crosstool/CodeSourcery/Sourcery_G++_Lite/bin/m68k-uclinux-ld.real: error: no memory region specified for loadable section `.text.unlikely' Any ideas on what might be wrong here and how I can get past this? Thanks, Dave From maxim at codesourcery.com Wed Nov 12 15:17:01 2008 From: maxim at codesourcery.com (Maxim Kuvyrkov) Date: Wed, 12 Nov 2008 16:17:01 +0100 Subject: [coldfire-gnu-discuss] Coldfire uclinux problem In-Reply-To: <491A78EA.4010205@meadorresearch.com> References: <491A78EA.4010205@meadorresearch.com> Message-ID: <491AF36D.2090703@codesourcery.com> Dave Meador wrote: > Hello, > > I tried to compile uclinux-dist-20080808 with > uClinux-dist-20080808-20080922.patch applied and with Freescale,M5475EVB > selected. I am using version Sourcery G++ Lite 4.3-45 compiler. Does the distro compile without the patch? > > All files compile, but the linker fails with the following linker error: > > LD init/built-in.o > LD vmlinux What is the real command line for invoking the linker? You may be able to obtain it by passing something like V=1 or VERBOSE=1 to make; e.g., 'make V=1'. > /opt/crosstool/CodeSourcery/Sourcery_G++_Lite/bin/m68k-uclinux-ld.real: > error: > no memory region specified for loadable section `.text.unlikely' > > Any ideas on what might be wrong here and how I can get past this? The linker script [either explicit or implicit] does not have instructions what to do with .text.unlikely section. You probably need to fix the linker script to handle the section; one way of doing this is to handle it in the same manner as .text section. -- Maxim From dave at meadorresearch.com Wed Nov 12 18:24:22 2008 From: dave at meadorresearch.com (Dave Meador) Date: Wed, 12 Nov 2008 10:24:22 -0800 Subject: [coldfire-gnu-discuss] Coldfire uclinux problem In-Reply-To: <491AF36D.2090703@codesourcery.com> References: <491A78EA.4010205@meadorresearch.com> <491AF36D.2090703@codesourcery.com> Message-ID: <491B1F56.1010300@meadorresearch.com> Hello Maxim, Maxim Kuvyrkov wrote: > Dave Meador wrote: >> Hello, >> >> I tried to compile uclinux-dist-20080808 with >> uClinux-dist-20080808-20080922.patch applied and with >> Freescale,M5475EVB selected. I am using version Sourcery G++ Lite >> 4.3-45 compiler. > > Does the distro compile without the patch? Yes, it does. >> >> All files compile, but the linker fails with the following linker error: >> >> LD init/built-in.o >> LD vmlinux > > What is the real command line for invoking the linker? You may be > able to obtain it by passing something like V=1 or VERBOSE=1 to make; > e.g., 'make V=1'. Here is the output of the linker command with V=1 : m68k-uclinux-ld -o vmlinux -T arch/m68knommu/kernel/vmlinux.lds arch/m68knommu/platform/coldfire/head.o init/built-in.o --start-group usr/built-in.o arch/m68knommu/kernel/built-in.o arch/m68knommu/mm/built-in.o arch/m68knommu/platform/coldfire/built-in.o arch/m68knommu/platform/5407/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a arch/m68knommu/lib/lib.a lib/built-in.o arch/m68knommu/lib/built-in.o drivers/built-in.o sound/built-in.o net/built-in.o --end-group /opt/crosstool/CodeSourcery/Sourcery_G++_Lite/bin/m68k-uclinux-ld.real: error: no memory region specified for loadable section `.text.unlikely' make[1]: *** [vmlinux] Error 1 make[1]: Leaving directory `./uClinux-dist/linux-2.6.x' make: *** [linux] Error 1 >> /opt/crosstool/CodeSourcery/Sourcery_G++_Lite/bin/m68k-uclinux-ld.real: >> error: >> no memory region specified for loadable section `.text.unlikely' >> >> Any ideas on what might be wrong here and how I can get past this? > > The linker script [either explicit or implicit] does not have > instructions what to do with .text.unlikely section. You probably > need to fix the linker script to handle the section; one way of doing > this is to handle it in the same manner as .text section. I found that the .text.unlikely and .text.hot section seems to be related to -freorder-functions option. I think this option may be triggered by the -O2 optimization flag. I updated the vmlinux.lds linker script to include the .text.hot and .text.unlikely and it compiled... but I have no idea if my additions are correct. Original vmlinux.lds: --- SECTIONS { .text : { _text = .; _stext = . ; *(.head.text) . = ALIGN(8); *(.text) *(.ref.text) *(.text.init.refok) *(.exit.text.refok) --- Modified vmlinux.lds: --- SECTIONS { .text : { _text = .; _stext = . ; *(.head.text) . = ALIGN(8); *(.text) *(.ref.text) *(.text.init.refok) *(.exit.text.refok) + . = ALIGN(8); *(.text.hot) *(.text.unlikely) --- I am not a linker script guru, so if you could give me some insight as to what is happening and what should be correct in your opinion? My very watered down understanding is that you would want to group often used functions (.text.hot) together which may allow performance benefits such as accessing fewer memory pages frequently. And put the less frequently used functions in a different area, perhaps far away from the frequently used memory? Thanks very much for your help, Dave From maxim at codesourcery.com Wed Nov 12 18:39:05 2008 From: maxim at codesourcery.com (Maxim Kuvyrkov) Date: Wed, 12 Nov 2008 19:39:05 +0100 Subject: [coldfire-gnu-discuss] Coldfire uclinux problem In-Reply-To: <491B1F56.1010300@meadorresearch.com> References: <491A78EA.4010205@meadorresearch.com> <491AF36D.2090703@codesourcery.com> <491B1F56.1010300@meadorresearch.com> Message-ID: <491B22C9.4080200@codesourcery.com> Dave Meador wrote: > Hello Maxim, ... > I am not a linker script guru, so if you could give me some insight as > to what is happening and what should be correct in your opinion? My > very watered down understanding is that you would want to group often > used functions (.text.hot) together which may allow performance benefits > such as accessing fewer memory pages frequently. And put the less > frequently used functions in a different area, perhaps far away from the > frequently used memory? I do not consider myself linker script expert either, but, fwiw, your fix and understanding look correct to me. -- Maxim From david at westcontrol.com Thu Nov 13 10:21:02 2008 From: david at westcontrol.com (David Brown) Date: Thu, 13 Nov 2008 11:21:02 +0100 Subject: Validation of gcc tools Message-ID: <491BFF8E.6040206@westcontrol.com> The question of development tools for various targets comes up regularly on comp.arch.embedded. It can often lead to disagreements between users and supporters of gcc, and those who feel that only commercial closed source tools are good enough for professional use. One of the key arguments from the closed-source camps is that they have tools that are validated and certified with Plum Hall and other such validation suites. Does anyone know if gcc has passed such validations, and for which targets and versions? mvh., David From mark at codesourcery.com Fri Nov 14 04:10:09 2008 From: mark at codesourcery.com (Mark Mitchell) Date: Thu, 13 Nov 2008 20:10:09 -0800 Subject: [coldfire-gnu-discuss] Validation of gcc tools In-Reply-To: <491BFF8E.6040206@westcontrol.com> References: <491BFF8E.6040206@westcontrol.com> Message-ID: <491CFA21.7070909@codesourcery.com> David Brown wrote: > The question of development tools for various targets comes up regularly > on comp.arch.embedded. It can often lead to disagreements between users > and supporters of gcc, and those who feel that only commercial closed > source tools are good enough for professional use. One of the key > arguments from the closed-source camps is that they have tools that are > validated and certified with Plum Hall and other such validation suites. We (CodeSourcery) validate each and every release, using a combination of open-source and closed-source testsuites. These include tests of the compiler, assembler, debugger, libraries, and other utilities. Many of the tests are in the open-source DejaGNU testsuite, which contains both feature tests and regression tests. As bugs are fixed in the tools, and as new features are added, new tests are added to these testsuites to ensure that they do not return. We do also use Plum-Hall for validation. GCC does not pass all tests in the Plum-Hall C or C++ validation testsuite, but it does pass the vast majority of them. Many of the failures are failures to issue error messages about technically invalid C or C++ code. There are also failures to accept valid corner-cases. (For example, in C++, you can overload based on whether not a particular function pointer type is extern "C"; G++ does not implement that.) We have automated tools that compare the hundreds of thousands of test results produced during each release to the expected results, and analyze any new failures, in general fixing those failures. Part of the value of Sourcery G++ is that validation effort. The GNU development community (including CodeSourcery) works hard to validate the tools, and part of the contribution process for GCC is running the testsuite to ensure that changes do not cause the compiler to regress. However, it is true that it is often the case that a change that works well on one developer's test machine may cause problems on another. And, some testsuites (like Plum-Hall) are only available to licensees and therefore not accessible to all developers. It is also true that differences in configuration, build process, and so forth can critically affect the reliability of the tools, even when building from the same source code. So, it is true that just downloading the GCC source code and building it yourself results in a compiler that is not nearly as well validated. We do patch official FSF releases to fix defects revealed through our testing. (Those patches are then contributed back to the FSF for inclusion in future versions of GCC.) In summary, the GNU toolchain as a whole is validated in part as part of the community development process. In addition, we then do significantly more testing, against the exact binaries we provide in our both our zero-cost and commercial releases. -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From maxim at codesourcery.com Sun Nov 16 19:31:37 2008 From: maxim at codesourcery.com (Maxim Kuvyrkov) Date: Sun, 16 Nov 2008 20:31:37 +0100 Subject: [coldfire-gnu-discuss] Bug in 2008Q3 release In-Reply-To: <490EE071.8060706@codesourcery.com> References: <490ECB5A.18100.D9F2385@meloun.miracle.cz> <490EE071.8060706@codesourcery.com> Message-ID: <49207519.2060508@codesourcery.com> Maxim Kuvyrkov wrote: > Meloun Michal wrote: >> Hello everybody! >> Unfortunately, I have problem with 2008Q3 release. >> GCC miscompile this small test case. > > Hello Meloun, > > Thank you for the bug report, we will investigate this. Continued at http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00762.html -- Maxim Kuvyrkov