From wayne at zk.com Mon May 4 00:23:01 2009 From: wayne at zk.com (Wayne) Date: Sun, 03 May 2009 17:23:01 -0700 Subject: GDB with Diab 4.3 Message-ID: <49FE3565.1010908@zk.com> We are currently using the Diab compiler with a proprietary (no longer supported) debugger. About a year ago I looked into using gdb and had it mostly working. At the time there were some support issues with the MCF 5474. At about the same time that the 5474 issues were addressed support for older versions of Dwarf were removed from the gdb so that it would no longer support the dwarf output by our version of the diab compiler. I don't remember all the version numbers and I can't seem to find my notes. At the time I was looking into using gdb as a convenience and I ran out of time to look into this. For various reasons I would like to try and get this working again. A long term goal would be switching completely over to gcc and gdb but gcc does not seem to be a short term option because some of the code we use is written in assembly for Diab. If I remember correctly Diab uses the Dwarf 2 standard and the Coldfire Gdb now uses Dwarf 3. Is there are way to use the current version of Gdb with binaries containing older version of the Dwarf format (either 1 or 2)? Is ther some sort of utility available to convert the debug information? Using GCC, at least for development work might be possible but we use a proprietary OS that is written in Diab assembly. Would it be possible to link in the object file compiled by Diab into a binary generated by GCC? Debugging the OS is rare and since it is written in assembly any way, source level debugging for it would not be a requirement. If anyone could answer these questions or point me in the right direction it would be greatly appreciated. We are using P&E BDM's. I also have access to a Macraigor 'Wiggler' Thanks, Wayne From mark at codesourcery.com Mon May 4 00:27:20 2009 From: mark at codesourcery.com (Mark Mitchell) Date: Sun, 03 May 2009 17:27:20 -0700 Subject: [coldfire-gnu-discuss] GDB with Diab 4.3 In-Reply-To: <49FE3565.1010908@zk.com> References: <49FE3565.1010908@zk.com> Message-ID: <49FE3668.5050703@codesourcery.com> Wayne wrote: > If I remember correctly Diab uses the Dwarf 2 standard and the Coldfire > Gdb now uses Dwarf 3. Is there are way to use the current version of Gdb > with binaries containing older version of the Dwarf format (either 1 or > 2)? Is ther some sort of utility available to convert the debug > information? GDB can read DWARF 2 binaries just fine. However, DWARF 2 isn't as standardized as you might think; different compilers tend to have different views of what the standard says in some respects. So, how well it will work is a bit of an open question. > Using GCC, at least for development work might be possible but we use a > proprietary OS that is written in Diab assembly. Would it be possible to > link in the object file compiled by Diab into a binary generated by GCC? Probably not. The Application Binary Interface for ColdFire just isn't that well-defined, or uniformly implemented. It *might* work, but you're likely to run into some problems. -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From wayne at zk.com Mon May 4 14:54:15 2009 From: wayne at zk.com (Wayne) Date: Mon, 04 May 2009 07:54:15 -0700 Subject: [coldfire-gnu-discuss] GDB with Diab 4.3 In-Reply-To: <49FE3668.5050703@codesourcery.com> References: <49FE3565.1010908@zk.com> <49FE3668.5050703@codesourcery.com> Message-ID: <49FF0197.8000405@zk.com> Mark Mitchell wrote: > Wayne wrote: > > >> If I remember correctly Diab uses the Dwarf 2 standard and the Coldfire >> Gdb now uses Dwarf 3. Is there are way to use the current version of Gdb >> with binaries containing older version of the Dwarf format (either 1 or >> 2)? Is ther some sort of utility available to convert the debug >> information? >> > > GDB can read DWARF 2 binaries just fine. However, DWARF 2 isn't as > standardized as you might think; different compilers tend to have > different views of what the standard says in some respects. So, how > well it will work is a bit of an open question. > > Yes, I was reading about ELF and seems to confirm what I was reading. The thing is that when I first starting trying to get gdb to work it seemed to read our binaries fine but was having support issues with the 5474. A short time later Code Sourcery released a version that worked with the 5474 but it no longer recognized the debug information in our binaries. I guess I will try the latest version. Maybe the dwarf problem was a bug in the release I tried.. Thanks, Wayne Wayne From dan at codesourcery.com Fri May 8 02:28:01 2009 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Thu, 7 May 2009 22:28:01 -0400 Subject: [coldfire-gnu-discuss] GDB with Diab 4.3 In-Reply-To: <49FF0197.8000405@zk.com> References: <49FE3565.1010908@zk.com> <49FE3668.5050703@codesourcery.com> <49FF0197.8000405@zk.com> Message-ID: <20090508022800.GY1334@caradoc.them.org> On Mon, May 04, 2009 at 07:54:15AM -0700, Wayne wrote: > Yes, I was reading about ELF and seems to confirm what I was reading. The > thing is that when I first starting trying to get gdb to work it seemed to > read our binaries fine but was having support issues with the 5474. A > short time later Code Sourcery released a version that worked with the > 5474 but it no longer recognized the debug information in our binaries. I > guess I will try the latest version. Maybe the dwarf problem was a bug in > the release I tried.. I suspect you were off by one on the version numbers. At one point, I know that Diab only produced DWARF version 1 output. And current GDB indeed does not support that. It should be easy to tell; if the ELF file has .debug_info, it's probably DWARF 2. I don't remember the names typically used by DWARF 1, but I think it's just ".debug". -- Daniel Jacobowitz CodeSourcery From wayne at zk.com Fri May 8 20:56:23 2009 From: wayne at zk.com (Wayne) Date: Fri, 08 May 2009 13:56:23 -0700 Subject: [coldfire-gnu-discuss] GDB with Diab 4.3 In-Reply-To: <20090508022800.GY1334@caradoc.them.org> References: <49FE3565.1010908@zk.com> <49FE3668.5050703@codesourcery.com> <49FF0197.8000405@zk.com> <20090508022800.GY1334@caradoc.them.org> Message-ID: <4A049C77.2050600@zk.com> An HTML attachment was scrubbed... URL: From dan at codesourcery.com Sun May 10 19:54:42 2009 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Sun, 10 May 2009 15:54:42 -0400 Subject: [coldfire-gnu-discuss] GDB with Diab 4.3 In-Reply-To: <4A049C77.2050600@zk.com> References: <49FE3565.1010908@zk.com> <49FE3668.5050703@codesourcery.com> <49FF0197.8000405@zk.com> <20090508022800.GY1334@caradoc.them.org> <4A049C77.2050600@zk.com> Message-ID: <20090510195442.GF1334@caradoc.them.org> On Fri, May 08, 2009 at 01:56:23PM -0700, Wayne wrote: > I think you are right, I seem to remember now that the version was 1.5. So > I guess that changes my question just a little bit. I know that Gdb was > working with our debug info, at least a little bit, until there was an > update to support the 5474. Is is possible to convert the 1.5 info to 2.0? > I would assume that some things would be missing. No, sorry - there are no conversion tools from DWARF 1 to DWARF 2. The information is too spotty. -- Daniel Jacobowitz CodeSourcery From Ken.Wong at christiedigital.com Wed May 27 19:33:54 2009 From: Ken.Wong at christiedigital.com (Wong, Ken) Date: Wed, 27 May 2009 15:33:54 -0400 Subject: 4.3-43 toolchain for mcf547x warnings Message-ID: <0384B41A03232C45B676D09A0173AB1E033721BD@cdskitexg01.cds.int> Using the 4.3-43 toolchain, I'm not getting the "too many arguments" warning when I compile the following sample code: #include static const char test[] = "%d"; int main() { int a = 0; int b = 1; printf (test, a, b); return 1; } But the warning does work if I use a string literal inside the printf... such as "printf ("%d", a, b);". I've tried the same code on the x86 gnu toolchain 3.4.6 successfully. Is there a flag that I'm forgetting to set in order to get the warning, or has the warning been removed from this version of the mcf547x 4.3-43 toolchain? Thanks, Ken Wong Product Developer, Software, Business Products CHRISTIE 809 Wellington Street North Kitchener, Ontario N2G 4Y7 PH: +1 519-744-8005 Ext. 7177 FX: +1 519-749-3164 www.christiedigital.com This e-mail message (including attachments, if any) is confidential. Any unauthorized use, distribution or disclosure is prohibited. If you have received this e-mail message in error, please notify the sender by reply e-mail or telephone and delete it and any attachments from your computer system and records. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxim at codesourcery.com Thu May 28 07:00:42 2009 From: maxim at codesourcery.com (Maxim Kuvyrkov) Date: Thu, 28 May 2009 11:00:42 +0400 Subject: [coldfire-gnu-discuss] 4.3-43 toolchain for mcf547x warnings In-Reply-To: <0384B41A03232C45B676D09A0173AB1E033721BD@cdskitexg01.cds.int> References: <0384B41A03232C45B676D09A0173AB1E033721BD@cdskitexg01.cds.int> Message-ID: <4A1E369A.7010206@codesourcery.com> Wong, Ken wrote: ... > I?ve tried the same code on the x86 gnu toolchain 3.4.6 successfully. > Is there a flag that I?m forgetting to set in order to get the warning, > or has the warning been removed from this version of the mcf547x 4.3-43 > toolchain? Hi Ken, It works for me with -Wformat GCC option: $ m68k-linux-gnu-gcc -c ./t.c -Wformat ./t.c: In function 'main': ./t.c:11: warning: too many arguments for format Also, you may find -Wall option useful, it enables a variety of useful warnings. -- Maxim CodeSourcery From mark at codesourcery.com Thu May 28 08:05:53 2009 From: mark at codesourcery.com (Mark Mitchell) Date: Thu, 28 May 2009 09:05:53 +0100 Subject: [coldfire-gnu-discuss] 4.3-43 toolchain for mcf547x warnings In-Reply-To: <0384B41A03232C45B676D09A0173AB1E033721BD@cdskitexg01.cds.int> References: <0384B41A03232C45B676D09A0173AB1E033721BD@cdskitexg01.cds.int> Message-ID: <4A1E45E1.4030005@codesourcery.com> Wong, Ken wrote: > Using the 4.3-43 toolchain, I?m not getting the ?too many arguments? > warning when I compile the following sample code: > static const char test[] = "%d"; > printf (test, a, b); GCC, unlike most compilers, issues different warnings depending on what optimizations are performed. If the compiler notices that the array is "const", and therefore substitutes the string into the "printf" call, then it will issue the warning. But, if it doesn't, then it will not. Whether that substitution occurs depends on the exact version of the compiler and what level of optimization is in use. Some users find this variability of warnings confusing. (I do, personally.) But, some people like the fact that the compiler can then offer warnings about cases like yours; many other compilers cannot issue such warnings because they do not do any optimization before issuing warnings. Thanks, -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From Ken.Wong at christiedigital.com Thu May 28 14:14:16 2009 From: Ken.Wong at christiedigital.com (Wong, Ken) Date: Thu, 28 May 2009 10:14:16 -0400 Subject: [coldfire-gnu-discuss] 4.3-43 toolchain for mcf547x warnings In-Reply-To: <4A1E45E1.4030005@codesourcery.com> References: <0384B41A03232C45B676D09A0173AB1E033721BD@cdskitexg01.cds.int> <4A1E45E1.4030005@codesourcery.com> Message-ID: <0384B41A03232C45B676D09A0173AB1E0337227E@cdskitexg01.cds.int> Maxim/Mark: thanks for all the info... I gave the -Wformat flag a try in our build system and didn't see the warning when compiling but everything that the both of you told me gives me enough to work with to look into it further. I'll send an update when I figure out what I'm doing wrong. :) Ken Wong Product Developer, Software, Business Products CHRISTIE 809 Wellington Street North Kitchener, Ontario N2G 4Y7 PH: +1 519-744-8005 Ext. 7177 FX: +1 519-749-3164 www.christiedigital.com This e-mail message (including attachments, if any) is confidential. Any unauthorized use, distribution or disclosure is prohibited. If you have received this e-mail message in error, please notify the sender by reply e-mail or telephone and delete it and any attachments from your computer system and records. -----Original Message----- From: Mark Mitchell [mailto:mark at codesourcery.com] Sent: Thursday, May 28, 2009 4:06 AM To: Wong, Ken Cc: coldfire-gnu-discuss at codesourcery.com Subject: Re: [coldfire-gnu-discuss] 4.3-43 toolchain for mcf547x warnings Wong, Ken wrote: > Using the 4.3-43 toolchain, I?m not getting the ?too many arguments? > warning when I compile the following sample code: > static const char test[] = "%d"; > printf (test, a, b); GCC, unlike most compilers, issues different warnings depending on what optimizations are performed. If the compiler notices that the array is "const", and therefore substitutes the string into the "printf" call, then it will issue the warning. But, if it doesn't, then it will not. Whether that substitution occurs depends on the exact version of the compiler and what level of optimization is in use. Some users find this variability of warnings confusing. (I do, personally.) But, some people like the fact that the compiler can then offer warnings about cases like yours; many other compilers cannot issue such warnings because they do not do any optimization before issuing warnings. Thanks, -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From mhench at elutions.com Thu May 28 14:17:01 2009 From: mhench at elutions.com (Mike Hench) Date: Thu, 28 May 2009 10:17:01 -0400 Subject: MCF547X/8X cache vs TAS instruction. Message-ID: The 'TAS' (test and set) instruction on the MCF548X cpu's bypasses the cache See section 5.5.1 of the reference manual. It is used in a few places for atomic locks. It doesn't play nice with the cache enabled. (for some horrible reason, the cache isn't enabled by default in freescale kernels, but that can be fixed) Locks are generally cleared with a simple write Which won't get to TAS readable (main) memory wirhout a flush. So TAS memory location --> to get a lock, main mem now has the bit set which may conflict with cached mem. Write 0 to clear lock (this is now only in cache, main mem still has lock bit set) TAS again to get a new lock and it see's the old bit in main mem since the cache has not been flushed to write the clear. The cache cannot be flushed/invalidated from user space because it uses privileged instructions. So the symptom is a hang waiting for a spinlock. 'bset' does a very similar thing however it is not SMP safe I don't see how that matters, who builds SMP boxes out of microcontrollers anyway? Bset is used for atomic locking in many places in the m68k code. Anyway this fixes the problem: (at least the ones I have seen) diff -aur glibc-linuxthreads-2.5.orig/linuxthreads/sysdeps/m68k/pspinlock.c glibc-linuxthreads-2.5/linuxthreads/sysdeps/m68k/pspinlock.c --- glibc-linuxthreads-2.5.orig/linuxthreads/sysdeps/m68k/pspinlock.c 2008-09-24 08:41:10.000000000 -0500 +++ glibc-linuxthreads-2.5/linuxthreads/sysdeps/m68k/pspinlock.c 2009-05-26 16:37:17.000000000 -0500 @@ -28,7 +28,7 @@ unsigned int val; do - asm volatile ("tas %1; sne %0" + asm volatile ("bset.b #7, %1; sne %0" : "=dm" (val), "=m" (*lock) : "m" (*lock) : "cc"); @@ -44,7 +44,7 @@ { unsigned int val; - asm volatile ("tas %1; sne %0" + asm volatile ("bset.b #7, %1; sne %0" : "=dm" (val), "=m" (*lock) : "m" (*lock) : "cc"); diff -aur glibc-linuxthreads-2.5.orig/linuxthreads/sysdeps/m68k/pt-machine.h glibc-linuxthreads-2.5/linuxthreads/sysdeps/m68k/pt-machine.h --- glibc-linuxthreads-2.5.orig/linuxthreads/sysdeps/m68k/pt-machine.h 2008-09-24 08:41:10.000000000 -0500 +++ glibc-linuxthreads-2.5/linuxthreads/sysdeps/m68k/pt-machine.h 2009-05-26 16:36:25.000000000 -0500 @@ -37,7 +37,7 @@ { char ret; - __asm__ __volatile__("tas %1; sne %0" + __asm__ __volatile__("bset.b #7, %1; sne %0" : "=dm"(ret), "=m"(*spinlock) : "m"(*spinlock) : "cc"); diff -aur gcc-4.3.orig/libstdc++-v3/config/cpu/m68k/atomicity.h gcc-4.3/libstdc++-v3/config/cpu/m68k/atomicity.h --- gcc-4.3.orig/libstdc++-v3/config/cpu/m68k/atomicity.h 2008-09-24 08:22:07.000000000 -0500 +++ gcc-4.3/libstdc++-v3/config/cpu/m68k/atomicity.h 2009-05-27 10:18:28.000000000 -0500 @@ -89,14 +89,14 @@ _Atomic_word __result; // bset with no immediate addressing (not SMP-safe) -#if defined(__mcfisaa__) || defined(__mcfisaaplus__) +#if defined(__mcfisaa__) || defined(__mcfisaaplus__) || defined(__mcfisab__) __asm__ __volatile__("1: bset.b #7,%0@\n\tjbne 1b" : /* no outputs */ : "a"(&_Atomicity_lock<0>::_S_atomicity_lock) : "cc", "memory"); // CPU32 and CF ISAs B & C support test-and-set (SMP-safe). -#elif defined(__mcpu32__) || defined(__mcfisab__) || defined (__mcfisac__) +#elif defined(__mcpu32__) || defined (__mcfisac__) __asm__ __volatile__("1: tas %0\n\tjbne 1b" : "+m"(_Atomicity_lock<0>::_S_atomicity_lock) : /* none */ -------------- next part -------------- An HTML attachment was scrubbed... URL: From agilgenbach at elutions.com Thu May 28 14:18:41 2009 From: agilgenbach at elutions.com (Alan Gilgenbach) Date: Thu, 28 May 2009 10:18:41 -0400 Subject: MCF547X/8X cache vs TAS instruction. In-Reply-To: References: Message-ID: Problem solved? Sincerely, Alan Gilgenbach Elutions 414 918 4269 From: Mike Hench Sent: Thursday, May 28, 2009 9:17 AM To: coldfire-gnu-discuss at codesourcery.com Cc: Rick Johnson; Alan Gilgenbach Subject: MCF547X/8X cache vs TAS instruction. The 'TAS' (test and set) instruction on the MCF548X cpu's bypasses the cache See section 5.5.1 of the reference manual. It is used in a few places for atomic locks. It doesn't play nice with the cache enabled. (for some horrible reason, the cache isn't enabled by default in freescale kernels, but that can be fixed) Locks are generally cleared with a simple write Which won't get to TAS readable (main) memory wirhout a flush. So TAS memory location ? to get a lock, main mem now has the bit set which may conflict with cached mem. Write 0 to clear lock (this is now only in cache, main mem still has lock bit set) TAS again to get a new lock and it see's the old bit in main mem since the cache has not been flushed to write the clear. The cache cannot be flushed/invalidated from user space because it uses privileged instructions. So the symptom is a hang waiting for a spinlock. 'bset' does a very similar thing however it is not SMP safe I don't see how that matters, who builds SMP boxes out of microcontrollers anyway? Bset is used for atomic locking in many places in the m68k code. Anyway this fixes the problem: (at least the ones I have seen) diff -aur glibc-linuxthreads-2.5.orig/linuxthreads/sysdeps/m68k/pspinlock.c glibc-linuxthreads-2.5/linuxthreads/sysdeps/m68k/pspinlock.c --- glibc-linuxthreads-2.5.orig/linuxthreads/sysdeps/m68k/pspinlock.c 2008-09-24 08:41:10.000000000 -0500 +++ glibc-linuxthreads-2.5/linuxthreads/sysdeps/m68k/pspinlock.c 2009-05-26 16:37:17.000000000 -0500 @@ -28,7 +28,7 @@ unsigned int val; do - asm volatile ("tas %1; sne %0" + asm volatile ("bset.b #7, %1; sne %0" : "=dm" (val), "=m" (*lock) : "m" (*lock) : "cc"); @@ -44,7 +44,7 @@ { unsigned int val; - asm volatile ("tas %1; sne %0" + asm volatile ("bset.b #7, %1; sne %0" : "=dm" (val), "=m" (*lock) : "m" (*lock) : "cc"); diff -aur glibc-linuxthreads-2.5.orig/linuxthreads/sysdeps/m68k/pt-machine.h glibc-linuxthreads-2.5/linuxthreads/sysdeps/m68k/pt-machine.h --- glibc-linuxthreads-2.5.orig/linuxthreads/sysdeps/m68k/pt-machine.h 2008-09-24 08:41:10.000000000 -0500 +++ glibc-linuxthreads-2.5/linuxthreads/sysdeps/m68k/pt-machine.h 2009-05-26 16:36:25.000000000 -0500 @@ -37,7 +37,7 @@ { char ret; - __asm__ __volatile__("tas %1; sne %0" + __asm__ __volatile__("bset.b #7, %1; sne %0" : "=dm"(ret), "=m"(*spinlock) : "m"(*spinlock) : "cc"); diff -aur gcc-4.3.orig/libstdc++-v3/config/cpu/m68k/atomicity.h gcc-4.3/libstdc++-v3/config/cpu/m68k/atomicity.h --- gcc-4.3.orig/libstdc++-v3/config/cpu/m68k/atomicity.h 2008-09-24 08:22:07.000000000 -0500 +++ gcc-4.3/libstdc++-v3/config/cpu/m68k/atomicity.h 2009-05-27 10:18:28.000000000 -0500 @@ -89,14 +89,14 @@ _Atomic_word __result; // bset with no immediate addressing (not SMP-safe) -#if defined(__mcfisaa__) || defined(__mcfisaaplus__) +#if defined(__mcfisaa__) || defined(__mcfisaaplus__) || defined(__mcfisab__) __asm__ __volatile__("1: bset.b #7,%0@\n\tjbne 1b" : /* no outputs */ : "a"(&_Atomicity_lock<0>::_S_atomicity_lock) : "cc", "memory"); // CPU32 and CF ISAs B & C support test-and-set (SMP-safe). -#elif defined(__mcpu32__) || defined(__mcfisab__) || defined (__mcfisac__) +#elif defined(__mcpu32__) || defined (__mcfisac__) __asm__ __volatile__("1: tas %0\n\tjbne 1b" : "+m"(_Atomicity_lock<0>::_S_atomicity_lock) : /* none */ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhench at elutions.com Thu May 28 14:34:53 2009 From: mhench at elutions.com (Mike Hench) Date: Thu, 28 May 2009 10:34:53 -0400 Subject: MCF547X/8X cache vs TAS instruction. In-Reply-To: Message-ID: Seems to be. ________________________________ From: Alan Gilgenbach Sent: Thursday, May 28, 2009 9:19 AM To: Mike Hench; 'coldfire-gnu-discuss at codesourcery.com' Cc: Rick Johnson Subject: RE: MCF547X/8X cache vs TAS instruction. Problem solved? Sincerely, Alan Gilgenbach Elutions 414 918 4269 From: Mike Hench Sent: Thursday, May 28, 2009 9:17 AM To: coldfire-gnu-discuss at codesourcery.com Cc: Rick Johnson; Alan Gilgenbach Subject: MCF547X/8X cache vs TAS instruction. The 'TAS' (test and set) instruction on the MCF548X cpu's bypasses the cache See section 5.5.1 of the reference manual. It is used in a few places for atomic locks. It doesn't play nice with the cache enabled. (for some horrible reason, the cache isn't enabled by default in freescale kernels, but that can be fixed) Locks are generally cleared with a simple write Which won't get to TAS readable (main) memory wirhout a flush. So TAS memory location --> to get a lock, main mem now has the bit set which may conflict with cached mem. Write 0 to clear lock (this is now only in cache, main mem still has lock bit set) TAS again to get a new lock and it see's the old bit in main mem since the cache has not been flushed to write the clear. The cache cannot be flushed/invalidated from user space because it uses privileged instructions. So the symptom is a hang waiting for a spinlock. 'bset' does a very similar thing however it is not SMP safe I don't see how that matters, who builds SMP boxes out of microcontrollers anyway? Bset is used for atomic locking in many places in the m68k code. Anyway this fixes the problem: (at least the ones I have seen) diff -aur glibc-linuxthreads-2.5.orig/linuxthreads/sysdeps/m68k/pspinlock.c glibc-linuxthreads-2.5/linuxthreads/sysdeps/m68k/pspinlock.c --- glibc-linuxthreads-2.5.orig/linuxthreads/sysdeps/m68k/pspinlock.c 2008-09-24 08:41:10.000000000 -0500 +++ glibc-linuxthreads-2.5/linuxthreads/sysdeps/m68k/pspinlock.c 2009-05-26 16:37:17.000000000 -0500 @@ -28,7 +28,7 @@ unsigned int val; do - asm volatile ("tas %1; sne %0" + asm volatile ("bset.b #7, %1; sne %0" : "=dm" (val), "=m" (*lock) : "m" (*lock) : "cc"); @@ -44,7 +44,7 @@ { unsigned int val; - asm volatile ("tas %1; sne %0" + asm volatile ("bset.b #7, %1; sne %0" : "=dm" (val), "=m" (*lock) : "m" (*lock) : "cc"); diff -aur glibc-linuxthreads-2.5.orig/linuxthreads/sysdeps/m68k/pt-machine.h glibc-linuxthreads-2.5/linuxthreads/sysdeps/m68k/pt-machine.h --- glibc-linuxthreads-2.5.orig/linuxthreads/sysdeps/m68k/pt-machine.h 2008-09-24 08:41:10.000000000 -0500 +++ glibc-linuxthreads-2.5/linuxthreads/sysdeps/m68k/pt-machine.h 2009-05-26 16:36:25.000000000 -0500 @@ -37,7 +37,7 @@ { char ret; - __asm__ __volatile__("tas %1; sne %0" + __asm__ __volatile__("bset.b #7, %1; sne %0" : "=dm"(ret), "=m"(*spinlock) : "m"(*spinlock) : "cc"); diff -aur gcc-4.3.orig/libstdc++-v3/config/cpu/m68k/atomicity.h gcc-4.3/libstdc++-v3/config/cpu/m68k/atomicity.h --- gcc-4.3.orig/libstdc++-v3/config/cpu/m68k/atomicity.h 2008-09-24 08:22:07.000000000 -0500 +++ gcc-4.3/libstdc++-v3/config/cpu/m68k/atomicity.h 2009-05-27 10:18:28.000000000 -0500 @@ -89,14 +89,14 @@ _Atomic_word __result; // bset with no immediate addressing (not SMP-safe) -#if defined(__mcfisaa__) || defined(__mcfisaaplus__) +#if defined(__mcfisaa__) || defined(__mcfisaaplus__) || defined(__mcfisab__) __asm__ __volatile__("1: bset.b #7,%0@\n\tjbne 1b" : /* no outputs */ : "a"(&_Atomicity_lock<0>::_S_atomicity_lock) : "cc", "memory"); // CPU32 and CF ISAs B & C support test-and-set (SMP-safe). -#elif defined(__mcpu32__) || defined(__mcfisab__) || defined (__mcfisac__) +#elif defined(__mcpu32__) || defined (__mcfisac__) __asm__ __volatile__("1: tas %0\n\tjbne 1b" : "+m"(_Atomicity_lock<0>::_S_atomicity_lock) : /* none */ -------------- next part -------------- An HTML attachment was scrubbed... URL: From list-bastian.schick at sciopta.com Fri May 29 04:29:33 2009 From: list-bastian.schick at sciopta.com (42Bastian) Date: Fri, 29 May 2009 06:29:33 +0200 Subject: [coldfire-gnu-discuss] MCF547X/8X cache vs TAS instruction. In-Reply-To: References: Message-ID: <4A1F64AD.3070006@sciopta.com> Mike > > 'bset' does a very similar thing however it is not SMP safe Just out of curiosity: How can you be sure "bset" cannot be interrupted? Do you have a reference ? -- 42Bastian From mhench at elutions.com Fri May 29 11:57:24 2009 From: mhench at elutions.com (Mike Hench) Date: Fri, 29 May 2009 07:57:24 -0400 Subject: [coldfire-gnu-discuss] MCF547X/8X cache vs TAS instruction. In-Reply-To: <4A1F64AD.3070006@sciopta.com> Message-ID: Search for the words "once per instruction" in the reference manual As in interrupts are sampled once per instruction It is mentioned in multiple places. Truth is I am assuming that once is between instructions. -----Original Message----- From: 42Bastian [mailto:list-bastian.schick at sciopta.com] Sent: Thursday, May 28, 2009 11:30 PM To: Mike Hench; coldfire-gnu-discuss at codesourcery.com Subject: Re: [coldfire-gnu-discuss] MCF547X/8X cache vs TAS instruction. Mike > > 'bset' does a very similar thing however it is not SMP safe Just out of curiosity: How can you be sure "bset" cannot be interrupted? Do you have a reference ? -- 42Bastian From list-bastian.schick at sciopta.com Fri May 29 17:15:15 2009 From: list-bastian.schick at sciopta.com (42Bastian) Date: Fri, 29 May 2009 19:15:15 +0200 Subject: [coldfire-gnu-discuss] MCF547X/8X cache vs TAS instruction. In-Reply-To: References: Message-ID: <4A201823.1040801@sciopta.com> Mike Hench schrieb: > Search for the words "once per instruction" in the reference manual > As in interrupts are sampled once per instruction > It is mentioned in multiple places. > Truth is I am assuming that once is between instructions. Right I would assume like this. For ARM I know as it is explicitly mentioned in the reference. Anyway leads me to think if I could use it for our RTOS :-) Cheers, -- 42Bastian