From Bernhard.Bender at bytecmed.com Mon Jun 10 16:29:45 2013 From: Bernhard.Bender at bytecmed.com (Bernhard Bender) Date: Mon, 10 Jun 2013 18:29:45 +0200 Subject: [arm-gnu] CS3 files for STM32F205 Message-ID: <6B919AC79333344DB0660E3FADEB2165044D38EF145A@BYTECEXCHGSRV.bytecexchg.local> Hi, we are useing the CodeSourcery Personal Edition 2013.05-26 and looking for the CS3 support for the STM32F2xx family of chips, namely the STM32F205ZF. The edition only seems to contain CS3 files for STM32F1xx and STM32F2xx MCUs. The problem that arises is that the JLink Debugger is unable to flash the MCU as it does not have the right flash memory setup. Thanks for any help. Bernhard Bender Entwicklung Bytec Medizintechnik GmbH Hermann-Hollerith-Str. 11 52249 Eschweiler, Germany Tel. +49 (2403) 7829-943 www.bytecmed.com Handelsregister Aachen: HRB 11222 Ust-ID: DE 121732719 Gesch?ftsf?hrer: Dipl.-Ing. Paul Willi Coenen Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender unter info at bytecmed.com und l?schen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This message may contain privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that any use, dissemination, distribution of reproduction of this message is prohibited. If you have received this message in error please notify info at bytecmed.com immediately. From abdurahman.alfeky at gmail.com Wed Jun 12 15:59:04 2013 From: abdurahman.alfeky at gmail.com (Abdurahman Alfeky) Date: Wed, 12 Jun 2013 17:59:04 +0200 Subject: [arm-gnu] gcc-arm Compiler produce different object file for the same source file Message-ID: Hi All , Have anyone face the following problem before: Using the GCC compiler for ARM (windows) : *arm-none-eabi-gcc.exe (Sourcery CodeBench Lite 2012.09-63) 4.7.2* version I have got different object file produced every ~5 times i compiled the same source file. The optimization level 3 is used (aggressive) is used, compiler options used: -O3 -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fshort-wchar -fshort-enums -funsafe-math-optimizations -mvectorize-with-neon-quad The dump of the different object files shows too many differences in assembly instructions , registers and addresses used. - Is it normal that compiler optimize/compile exactly the same source file differently and produce different object files ?! is it a compiler bug ? - How to avoid this behavior without turning off aggressive optimization ? Thanks -- Abdurahman Alfeky, Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at westcontrol.com Thu Jun 13 07:30:07 2013 From: david at westcontrol.com (David Brown) Date: Thu, 13 Jun 2013 09:30:07 +0200 Subject: [arm-gnu] gcc-arm Compiler produce different object file for the same source file In-Reply-To: References: Message-ID: <51B974FF.2060808@westcontrol.com> On 12/06/13 17:59, Abdurahman Alfeky wrote: > Hi All , > > Have anyone face the following problem before: > > Using the GCC compiler for ARM (windows) : > > /arm-none-eabi-gcc.exe (Sourcery CodeBench Lite 2012.09-63) 4.7.2/ > version > > I have got different object file produced every ~5 times i compiled the > same source file. > > The optimization level 3 is used (aggressive) is used, compiler options > used: > > -O3 -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fshort-wchar > -fshort-enums -funsafe-math-optimizations -mvectorize-with-neon-quad > > The dump of the different object files shows too many differences in > assembly instructions , registers and addresses used. > > * > > Is it normal that compiler optimize/compile exactly the same source > file differently and produce different object files ?! is it a > compiler bug ? > > * > > How to avoid this behavior without turning off aggressive optimization ? > > Thanks > There are usually differences in the object file, because it includes things like compilation date in the debugging information. But I don't think you should get differences in the actual generated code. Are you sure there is nothing changing, like headers, use of __DATE__ macros, etc.? Minor changes in the source code can sometimes lead to apparently large changes in the object code such as different register choices or different ordering of code (the behaviour of such code is identical, but it can look very different). If you are looking at the final linked code, then remember that the order of the object files in the link can often affect the order of the generated code. From abdurahman.alfeky at gmail.com Thu Jun 13 09:47:41 2013 From: abdurahman.alfeky at gmail.com (Abdurahman Alfeky) Date: Thu, 13 Jun 2013 11:47:41 +0200 Subject: [arm-gnu] gcc-arm Compiler produce different object file for the same source file In-Reply-To: <51B974FF.2060808@westcontrol.com> References: <51B974FF.2060808@westcontrol.com> Message-ID: there is no chnagein source code , and there no use of __DATE__ or time macros , no regenerated headers and by looking into the output of objdump on object file which is compiled without debugging information i can see too many differences in assembly instructions. i heard about using -frandom-seed=string to avoid this but it is not clear how the compiler deal with it ? copied from man page " http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html" > -frandom-seed=stringThis option provides a seed that GCC uses in place of > random numbers in generating certain symbol names that have to be different > in every compiled file. It is also used to place unique stamps in coverage > data files and the object files that produce them. You can use the > -frandom-seed option to produce reproducibly identical object files. > > The string should be different for every file you compile > On Thu, Jun 13, 2013 at 9:30 AM, David Brown wrote: > On 12/06/13 17:59, Abdurahman Alfeky wrote: > > Hi All , > > > > Have anyone face the following problem before: > > > > Using the GCC compiler for ARM (windows) : > > > > /arm-none-eabi-gcc.exe (Sourcery CodeBench Lite 2012.09-63) 4.7.2/ > > version > > > > I have got different object file produced every ~5 times i compiled the > > same source file. > > > > The optimization level 3 is used (aggressive) is used, compiler options > > used: > > > > -O3 -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fshort-wchar > > -fshort-enums -funsafe-math-optimizations -mvectorize-with-neon-quad > > > > The dump of the different object files shows too many differences in > > assembly instructions , registers and addresses used. > > > > * > > > > Is it normal that compiler optimize/compile exactly the same source > > file differently and produce different object files ?! is it a > > compiler bug ? > > > > * > > > > How to avoid this behavior without turning off aggressive > optimization ? > > > > Thanks > > > > There are usually differences in the object file, because it includes > things like compilation date in the debugging information. But I don't > think you should get differences in the actual generated code. Are you > sure there is nothing changing, like headers, use of __DATE__ macros, > etc.? Minor changes in the source code can sometimes lead to apparently > large changes in the object code such as different register choices or > different ordering of code (the behaviour of such code is identical, but > it can look very different). > > If you are looking at the final linked code, then remember that the > order of the object files in the link can often affect the order of the > generated code. > > > _______________________________________________ > arm-gnu mailing list > arm-gnu at codesourcery.com > http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu > -- Abdurahman Alfeky, Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricardo_anguiano at mentor.com Thu Jun 13 15:56:12 2013 From: ricardo_anguiano at mentor.com (Ricardo Anguiano) Date: Thu, 13 Jun 2013 08:56:12 -0700 Subject: [arm-gnu] gcc-arm Compiler produce different object file for the same source file In-Reply-To: References: <51B974FF.2060808@westcontrol.com> Message-ID: <51B9EB9C.5080401@mentor.com> Hello Abudurahman, We'll need more information. The GCC bug reporting instructions (under the _What we need_ heading) are a good template to use when reporting possible problems or difficulties with GCC: http://gcc.gnu.org/bugs/ Do you have a small preprocessed test case file (-save-temps, *.i* output) you can send to the list? Thanks, -- Ricardo Anguiano Mentor Graphics +1-510-354-6774 On 6/13/2013 2:47 AM, Abdurahman Alfeky wrote: > there is no chnagein source code , and there no use of __DATE__ or time macros , no regenerated headers and by looking into the output of objdump on object file which is compiled without debugging information i can see too many differences in assembly instructions. i heard about using -frandom-seed=string to avoid this but it is not clear how the compiler deal with it ? > > copied from man page "http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html" > > |-frandom-seed=|string > This option provides a seed that GCC uses in place of random numbers in generating certain symbol names that have to be different in every compiled file. It is also used to place unique stamps in coverage data files and the object files that produce them. You can use the -frandom-seed option to produce reproducibly identical object files. > > The string should be different for every file you compile > > > > > On Thu, Jun 13, 2013 at 9:30 AM, David Brown > wrote: > > On 12/06/13 17:59, Abdurahman Alfeky wrote: > > Hi All , > > > > Have anyone face the following problem before: > > > > Using the GCC compiler for ARM (windows) : > > > > /arm-none-eabi-gcc.exe (Sourcery CodeBench Lite 2012.09-63) 4.7.2/ > > version > > > > I have got different object file produced every ~5 times i compiled the > > same source file. > > > > The optimization level 3 is used (aggressive) is used, compiler options > > used: > > > > -O3 -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fshort-wchar > > -fshort-enums -funsafe-math-optimizations -mvectorize-with-neon-quad > > > > The dump of the different object files shows too many differences in > > assembly instructions , registers and addresses used. > > > > * > > > > Is it normal that compiler optimize/compile exactly the same source > > file differently and produce different object files ?! is it a > > compiler bug ? > > > > * > > > > How to avoid this behavior without turning off aggressive optimization ? > > > > Thanks > > > > There are usually differences in the object file, because it includes > things like compilation date in the debugging information. But I don't > think you should get differences in the actual generated code. Are you > sure there is nothing changing, like headers, use of __DATE__ macros, > etc.? Minor changes in the source code can sometimes lead to apparently > large changes in the object code such as different register choices or > different ordering of code (the behaviour of such code is identical, but > it can look very different). > > If you are looking at the final linked code, then remember that the > order of the object files in the link can often affect the order of the > generated code. > > > _______________________________________________ > arm-gnu mailing list > arm-gnu at codesourcery.com > http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu > > > > > -- > Abdurahman Alfeky, > Software Engineer > > > > _______________________________________________ > arm-gnu mailing list > arm-gnu at codesourcery.com > http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu > From gds at chartertn.net Mon Jun 17 03:36:05 2013 From: gds at chartertn.net (Gene Smith) Date: Sun, 16 Jun 2013 23:36:05 -0400 Subject: [arm-gnu] gcc-arm Compiler produce different object file for the same source file In-Reply-To: References: Message-ID: <51BE8425.2040709@chartertn.net> On 06/12/2013 11:59 AM, Abdurahman Alfeky wrote: > Hi All , > > Have anyone face the following problem before: > > Using the GCC compiler for ARM (windows) : > > /arm-none-eabi-gcc.exe (Sourcery CodeBench Lite 2012.09-63) 4.7.2/ > version > > I have got different object file produced every ~5 times i compiled the > same source file. > > The optimization level 3 is used (aggressive) is used, compiler options > used: > > -O3 -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fshort-wchar > -fshort-enums -funsafe-math-optimizations -mvectorize-with-neon-quad > > The dump of the different object files shows too many differences in > assembly instructions , registers and addresses used. > > * > > Is it normal that compiler optimize/compile exactly the same source > file differently and produce different object files ?! is it a > compiler bug ? > > * > > How to avoid this behavior without turning off aggressive optimization ? > > Thanks > > -- > Abdurahman Alfeky, > Software Engineer > Tried with latest CS lite eabi version 4.7.3 and don't see a problem. After linking big cortex-m3 pgm I object dump the elf to ihex file. Then run a md5 checksum on the ihex file and it is always the same md5 value even after 6+ "make clean all" runs. But not same options (or processor) and not 4.7.2 so just a data point and not an exact comparison, so still may be a bug. From gds at chartertn.net Mon Jun 17 04:04:19 2013 From: gds at chartertn.net (Gene Smith) Date: Mon, 17 Jun 2013 00:04:19 -0400 Subject: [arm-gnu] gcc-arm Compiler produce different object file for the same source file In-Reply-To: <51BE8425.2040709@chartertn.net> References: <51BE8425.2040709@chartertn.net> Message-ID: <51BE8AC3.8000007@chartertn.net> On 06/16/2013 11:36 PM, Gene Smith wrote: > > Tried with latest CS lite eabi version 4.7.3 and don't see a problem. > After linking big cortex-m3 pgm I object dump the elf to ihex file. Then > run a md5 checksum on the ihex file and it is always the same md5 value > even after 6+ "make clean all" runs. But not same options (or processor) > and not 4.7.2 so just a data point and not an exact comparison, so still > may be a bug. > Forgot to mention that also using -O3 when doing builds. Also, never saw this problem with older version cs/gcc 4.5.2 at any -O level.