On Mon, Nov 27, 2017 at 12:32:28PM +0100, David Brown wrote:
> > doing an asm("nop") seems to do the job for gcc, and I guess (not
> > verified) would be portable across architectures, so for gcc/gdb combo
> > I will do this.
>
> Most targets have a "nop" instruction, but not all.
>From gcc/testsuite/gcc.dg/nop.h:
#if defined (__ia64__) || defined (__s390__) || defined (__s390x__)
#define NOP "nop 0"
#elif defined (__MMIX__)
#define NOP "swym 0"
#else
#define NOP "nop"
#endif
> I would recommend you use:
>
> asm volatile ("nop" ::: "memory");
>
> The "volatile" limits re-ordering somewhat
No, it doesn't: to start with, this asm *always* is volatile (it has no
outputs, asms without outputs are always volatile).
Just use asm("nop"); unless you really really really need something
else (and then you *know* you do, instead of cargo-culting something).
> and ensures it is "executed"
> at that point in the code. The memory clobber tells gcc to write out
> the values of any variables in memory before the instruction, and read
> them in again after the instruction - this will make your variable view
> in the debugger more accurate (since the compiler won't move variable
> changes across the breakpoint).
That is misleading. The compiler is perfectly free to keep variables
in registers (unless those variables are *also* volatile, or have their
address taken, etc.)
If you want easier debugging, use -O0 or -Og.
Segher
