dynamic tracing problem

dynamic tracing problem

[Joe Buehler]

I am attempting to use inline assembly to implement a tracing mechanism that
results in code something like this (asm syntax not meant to be exact):

"pre" C code...

/* via inline asm */
j trace
.pushsubsection 1000
trace:

"trace" C code...

/* via inline asm */
j post
.popsubsection
post:

"post" C code...

The idea is that the trace code can be nullified by changing the "j trace"
instruction to a NOP or activated by putting the jump back.

I have an implementation and it almost works.  It malfunctions when applied on a
large scale.  I assume it is malfunctioning because gcc has placed essential
side-effects in the trace block.

How can I tell gcc not to move anything past the first asm?

How can I tell it to not expect any computations in the trace block to get past
the second asm?

Both asm statements are currently volatile.  I have experimented a little with
"memory" clobbers without success.  I need some help from an expert here.

I am using gcc 4.1 and 4.3.3 if it matters.

Joe Buehler

Re: dynamic tracing problem

[Ian Lance Taylor]

Joe Buehler <aspam@cox.net> writes:

> I am attempting to use inline assembly to implement a tracing mechanism that
> results in code something like this (asm syntax not meant to be exact):
>
> "pre" C code...
>
> /* via inline asm */
> j trace
> .pushsubsection 1000
> trace:
>
> "trace" C code...
>
> /* via inline asm */
> j post
> .popsubsection
> post:
>
> "post" C code...
>
> The idea is that the trace code can be nullified by changing the "j trace"
> instruction to a NOP or activated by putting the jump back.

I don't see how this can work reliably in gcc when optimizing.  gcc
freely rearranges blocks, and there is no way to prevent that.  If there
are any blocks between "trace" and "post", they may get moved out of the
subsection.  It's even possible that other blocks will get moved into
the subsection.

Ian

Re: dynamic tracing problem

[Joe Buehler]

On 10/7/11 9:09 PM, Ian Lance Taylor wrote:
> I don't see how this can work reliably in gcc when optimizing. gcc freely rearranges blocks, and there is no way to prevent that. If there are any blocks between "trace" and "post", they may get moved out of the subsection. It's even possible that other 
> blocks will get moved into the subsection. Ian 
OK.  I misunderstood what volatile asm ("" : : : "memory") does -- it is not a general code motion barrier, just a motion barrier to compiler-issued reads and writes.

I changed my approach to something like this:

int tmp;
asm volatile ("li %0,0" : "=r"(tmp)); // MIPS load immediate
if (__builtin_expect(!!tmp, 0)) {

C trace code here...

}

By changing the load instruction I can enable and disable the trace code at runtime.  It may not be as efficient as the previous approach because of the conditional branch but has the advantage of being very straightforward to understand.

Thanks for the help.

Joe Buehler