This is the mail archive of the 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: [RFC] asm goto

GCC's asm support is widely regarded as the messiest asm syntax of any compiler. Writing it is highly error-prone even for regular GCC contributors and kernel hackers! Please think very carefully before extending it instead of replacing it.

What I see here is a specific hack to enable what is probably a DTrace- like facility in a single specific kernel. It relies on non-obvious block-rearranging behavior that is not stated in the source code. This looks highly fragile!

Instead of hacking the compiler to support this one use case, why don't we try to help improve the design instead? For example, I don't see (for most CPU types) why there needs to be more than one call to trace() in the program.


On Jul 27, 2009, at 2:28 PM, Richard Henderson wrote:

Some prodding from the kernel folk here at Red Hat has lead me to implementing a mechanism by which an asm statement can branch to a C label.

There is a major restriction on this form of asm statement, in that we cannot support output reloads on jump instructions, and therefore we cannot support outputs from the branching asm.

However, the usage case from the kernel folk doesn't actually need outputs. They want to perform some code patching for (essentially) zero cost tracing. Their use case looks vaguely like

+#define TRACE1(NUM)                         \
+  do {                                      \
+    asm goto ("0: nop;"                     \
+              ".pushsection trace_table;"   \
+              ".long 0b, %l0;"              \
+              ".popsection"                 \
+             : : : : trace#NUM);           \
+    if (0) { trace#NUM: trace(); }          \
+  } while (0)
+#define TRACE  TRACE1(__COUNTER__)

where instances of the TRACE macro get sprinkled about the kernel. It's expected that the compiler rearranges the blocks here such that the straight-line code path normally consists of only the nop insn. But we've recorded enough information in the trace_table section to allow that nop insn to be patched to be direct jump to the trace#NUM label, which calls the trace function followed by a branch back into the straight-line code.

I've implemented this only for the C front-end at present, awaiting feedback that might change the syntax. I'll adjust the C++ front end and add a bunch of parsing test cases following general approval of the idea.

So. Comments?

r~ <d-asmgoto-2.txt>

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