Re: How to avoid code elimination

[phi gcc <phi dot gcc at gmail dot com>]

Interesting discution, thanx you all :)

Well, as I said I did try asm("nop"), and it looked like it was doing
the job so I stopped there, and I was indeed aware that if I bumped
into a no nop arch, I would be able to find the NOP equiv like
r0=r0|r0 i.e OR r0,r0,r0 etc... on some well beloved and disapeared
arch.

I did use -O0 and didn't knew -Og, assumed -g implied no
optimisations, until one would force -g -O2 that would setup the
compiler to genereate DOC (debug optimised code)


Cheers,
Phi


On Mon, Nov 27, 2017 at 11:12 PM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
> 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