From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5825 invoked by alias); 19 Feb 2014 14:11:15 -0000 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 Received: (qmail 5811 invoked by uid 89); 19 Feb 2014 14:11:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oa0-f50.google.com Received: from mail-oa0-f50.google.com (HELO mail-oa0-f50.google.com) (209.85.219.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 19 Feb 2014 14:11:10 +0000 Received: by mail-oa0-f50.google.com with SMTP id n16so453148oag.23 for ; Wed, 19 Feb 2014 06:11:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oAv1K/zx03ltEKgqnxluadrYY6PpLv0nmMDCsVz7x+0=; b=UmjUpK/04n5Lp0V7DTNcdvG3E/+BUDTrpsAHF8Zsm5g6DkoOskNGh0sPLSLctvqopS ZTjwnNSKiahQlRUQ0BGJx0SmZPHQHQQXM3W6VOOt/9qJWvfz4/w0zrAIXUXjZ1zbaaix A9FCkuiNACdZozJ9iiP3AdT4+SMqYXO+G+SzgnLGdtraYGK3wJ59iqMsAqNow/8duGNo oF6ZFVV/1R2oWiYcvYG16t4aVHb7EgaELzzDM6jEKa0gfUHb3/3l9BBRlrHmbM9EczYH 89S+WBtJP+vtPUOSuHNmuCqp3dTFdQwRRJuJuy+wehw4ePsKgOcetSs1XRx6qB2dkHNs y90w== X-Gm-Message-State: ALoCoQmhqCxwr/FlHoQQI78JztTYiBasC/hSTG/3pNQ03NztM9QkG3hwBQm3eG84xsQkO/su/IJHFQHr35oClii/EfoPxwhiVJ+9pEWR8Ab+KWgmagYt4BIjnPZt0edIk1uUvZAf/1jHFCyCx2y4VHYi0Eru3C2M9ufYa66S7uYetFwKEDiFKGdDfkhMASxQ58366gFetB95 MIME-Version: 1.0 X-Received: by 10.60.62.199 with SMTP id a7mr1420501oes.64.1392819069045; Wed, 19 Feb 2014 06:11:09 -0800 (PST) Received: by 10.60.39.2 with HTTP; Wed, 19 Feb 2014 06:11:08 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Feb 2014 14:11:00 -0000 Message-ID: Subject: Re: Moving C++ code to a different ELF section From: Ian Lance Taylor To: Saul Tamari Cc: "gcc-help@gcc.gnu.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00108.txt.bz2 On Wed, Feb 19, 2014 at 5:57 AM, Saul Tamari wrote: > > I'm trying to move some C++ code to a different ELF section and am > facing some errors which I don't understand. I'm using g++ v4.8.1 on > x86. > > When compiling the following code I'm getting these errors: > /tmp/ccpp2AkE.s: Assembler messages: > /tmp/ccpp2AkE.s:63: Error: CFI instruction used without previous .cfi_startproc > /tmp/ccpp2AkE.s:64: Error: CFI instruction used without previous .cfi_startproc > /tmp/ccpp2AkE.s:66: Error: .cfi_endproc without corresponding .cfi_startproc > /tmp/ccpp2AkE.s: Error: open CFI at the end of file; missing > .cfi_endproc directive > > > The source is: > #include > #include > > int qqq; > > int main(int argc, char* argv[]) > { > std::cout << "hey " << std::endl; > > qqq = rand(); > if (qqq > 0x1000000) { > asm volatile ("jmp 1f \n\t .pushsection > __kuku,\"ax\",@progbits \n\t 1:"); > std::cout << "0x123456" << std::endl; > throw 12345; > asm volatile("jmp 3f \n\t .popsection \n\t 3:"); > } > > return 0; > } > > > What do these errors mean? Is there a way to fix them? Is there an > alternate method to move similar code to a different section? The assembler errors occur because GCC emits debug info in the assembler stream using CFI pseudo-ops, and you are moving the pseudo-ops to a different section in a way that GCC does not understand. The assembler is seeing CFI pseudo-ops that make no sense, so it is giving errors about them. The approach you are using can not work. The compiler is not an assembler. It does not issue instructions in precise sequence. It copies and duplicates and rearranges instructions as it sees fit. This is so even though you are using asm volatile. All the asm volatile promises is that the string will appear at the right point in execution sequence. Your strings can only work if they appear at the right point in the assembler output. That is a different matter that the compiler does not guarantee. You didn't see what you are trying to do, but at a guess you should look at the -freorder-blocks-and-partition option. Ian