From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26329 invoked by alias); 8 Oct 2011 15:11:25 -0000 Received: (qmail 26321 invoked by uid 22791); 8 Oct 2011 15:11:24 -0000 X-SWARE-Spam-Status: No, hits=0.3 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from eastrmfepo102.cox.net (HELO eastrmfepo102.cox.net) (68.230.241.214) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 08 Oct 2011 15:11:05 +0000 Received: from eastrmimpo109.cox.net ([68.230.241.222]) by eastrmfepo102.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20111008151059.PLVW12239.eastrmfepo102.cox.net@eastrmimpo109.cox.net>; Sat, 8 Oct 2011 11:10:59 -0400 Received: from thunder.sweets ([68.100.141.95]) by eastrmimpo109.cox.net with bizsmtp id iFAz1h00G23hm2k02FAzb7; Sat, 08 Oct 2011 11:10:59 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-Spam: 0 X-Authority-Analysis: v=1.1 cv=6rx5rrop0B/3XsMRrR1KrzZMeFjRjT2p3ZIkrGo5W8Y= c=1 sm=1 a=9NQzYnUODMYA:10 a=G8Uczd0VNMoA:10 a=8nJEP1OIZ-IA:10 a=NpDSbZnL7oWxO3tJXEQWVQ==:17 a=Nfo1Xv7xoX-eQdUg7FEA:9 a=wPNLvfGTeEIA:10 a=NpDSbZnL7oWxO3tJXEQWVQ==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Received: from mini.sweets (mini.sweets [10.10.10.31]) by thunder.sweets (Postfix) with ESMTP id DBC3110E1D; Sat, 8 Oct 2011 11:10:58 -0400 (EDT) Message-ID: <4E906801.6070402@cox.net> Date: Sat, 08 Oct 2011 15:11:00 -0000 From: Joe Buehler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ian Lance Taylor CC: gcc-help@gcc.gnu.org Subject: Re: dynamic tracing problem References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg00051.txt.bz2 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