This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How to avoid code elimination


On 27/11/17 11:18, phi gcc wrote:
> HI David,
> 
> I can't really do 'volatile' because as I said, I used to borow
> whatever scalar I found in the C code vincinity (at a glance) that I
> can nopify.
> 
> In short it is a quick and dirty setting of a conditioned BP, the
> condition can be raised after million iteration, so just setting a BP
> and asking GDB to continue until the right cond is arrived is way to
> slow, so I code the condition in C
> 
> if(cond)
> {
> }
> 
> then I need a BP in the if(){} , then I need an instruction to stick
> into the {} and e=e x=x is a good quick and dirty way to do it, even
> though I don't own e or x here, so I can't volatilize it.
> 

You can make a new volatile:

if (cond) {
	volatile v = 123;
}

If you want to be sure you can read the value of "e" when the breakpoint
hits, then try:

if (cond) {
	volatile ve = e;
}


> Since I said the word, I want a nop in there, so let's be it a real nop :).
> 
> Remember I said right at the begining I am new to gcc, and I used
> other 'older' C compilers that bearly had a  asm() backdoor, so the
> e=e trick was ok, because -g trig a no-optimisation :)

gcc is smarter than most other compilers.  It is even smarter than many
when optimisation is disabled in gcc.

> 
> 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.

I would recommend you use:

	asm volatile ("nop" ::: "memory");

The "volatile" limits re-ordering somewhat 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).

> 
> I noted as you mentioned that the various optimisations make single
> step (at C level, not asm instruction) some source bouncing but that's
> ok, since I use the -tui, I got the ^L key that start melting but I
> can remap :)
> 
> Cheers,
> Phi
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]