From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30467 invoked by alias); 7 Oct 2011 19:20:20 -0000 Received: (qmail 30457 invoked by uid 22791); 7 Oct 2011 19:20:20 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 07 Oct 2011 19:20:06 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RCFxk-0003Ni-T5 for gcc-help@gcc.gnu.org; Fri, 07 Oct 2011 21:20:05 +0200 Received: from netrokpix001.spirentcom.com ([96.241.21.98]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 Oct 2011 21:20:04 +0200 Received: from aspam by netrokpix001.spirentcom.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 Oct 2011 21:20:04 +0200 To: gcc-help@gcc.gnu.org From: Joe Buehler Subject: dynamic tracing problem Date: Fri, 07 Oct 2011 19:20:00 -0000 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: Loom/3.14 (http://gmane.org/) X-IsSubscribed: yes 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/msg00044.txt.bz2 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