From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by sourceware.org (Postfix) with ESMTPS id 093193854801 for ; Fri, 26 Feb 2021 07:09:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 093193854801 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maskray.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=emacsray@gmail.com Received: by mail-pl1-f170.google.com with SMTP id w18so4808023plc.12 for ; Thu, 25 Feb 2021 23:09:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ymp8jzvXoZbhDYzciArpeMv3xvTQCc2Q1xx75b211wY=; b=VIuwjDkX0ohgWTurDEMYAibrbKyTSkWBVgEVdZ9u8bgQBOYhirWghxuSqBHHNOD87a ie+SgUT11mmsTbsexQEfABdxW/8Y7QtNntCzaPcMZHE6/4MqpnrgfGItPnVOsKAnypqb LKEx7CxWkXq2DcufGScg4j/w50RoYqku7y00ScTjQVdgnx6ivulKsseIVOodr3tavNv4 LabrWO66v10v5AJZF0v+m/HoTevrG2WKhfl8Yz4JYdpHLXGX0pVAb9FC8fNCBMoMJ5oo f5if9EWqz0IZd3ZtD/6L0WyfAIXkWrRZ5SIid1dIyNAxsGEBUps3RvUAplIEyUR29N0H fFaA== X-Gm-Message-State: AOAM533semlFG7Mra3fbwV1VxuqxyizU0IyLSI+Dk5puPcGfd5OyC0tA yK9E/Tbd+VF6UY1cUEcYOho= X-Google-Smtp-Source: ABdhPJybQja/mbZKKtp/H3KoFCLHFPwTPz6mHFIba24Af82Y9k5Q6ZqKG8Axayzg0A925hCea3poZQ== X-Received: by 2002:a17:902:e54e:b029:de:8c70:2ec4 with SMTP id n14-20020a170902e54eb02900de8c702ec4mr2061500plf.56.1614323347146; Thu, 25 Feb 2021 23:09:07 -0800 (PST) Received: from localhost ([2601:647:4b01:ae80:8954:7148:c032:ba4c]) by smtp.gmail.com with ESMTPSA id p19sm7911023pjo.7.2021.02.25.23.09.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Feb 2021 23:09:06 -0800 (PST) Date: Thu, 25 Feb 2021 23:09:05 -0800 From: Fangrui Song To: Jim Wilson Cc: Segher Boessenkool , gcc-help Subject: Re: Why does -g force .cfi_* directives? Message-ID: <20210226070905.e5s3pu6u5ei74zrn@gmail.com> References: <20210220003611.kyctkqaz3m2weqva@gmail.com> <20210220194353.GT28121@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20210220194353.GT28121@gate.crashing.org> X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_INFOUSMEBIZ, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2021 07:09:10 -0000 On 2021-02-20, Segher Boessenkool wrote: >Hi! > >On Fri, Feb 19, 2021 at 07:53:13PM -0800, Jim Wilson wrote: >> On Fri, Feb 19, 2021 at 4:36 PM Fangrui Song wrote: >> > How should we make the following code work with both >> > -fno-asynchronous-unwind-tables and -fasynchronous-unwind-tables? >> > >> > int main() { >> > asm(".cfi_undefined %rip"); >> > } >> > >> >> I don't think that there is a way currently to make this work. >> >> In general, I'd say that if you are doing something non-trivial you should >> not be using an extended asm. You should either use a built-in function or >> just write it in assembly language directly. Extended asms really only >> work well for simple stuff. If you use a built-in function, then the >> compiler should emit any CFI directives for that built-in if necessary. If >> writing in assembly language then you can hand write CFI directives for the >> entire function, or rely on assembler support if the assembler can figure >> it out from the code. > >[ Well, I wouldn't say "non-trivial"... But "more than a few machine >instructions", or "something that uses assembler pseudo-ops that aren't >set up for this (with push/pop for example), I certainly agree with it >if put that way. ] > >An inline asm inserts a piece of text in the middle of the compiler >output. You aren't even guaranteed it will be in *this* function, it >could be inlined, and could be cloned, etc. Or deleted. > >That can be dealt with by using a noipa attribute. But then you get the >next problem: > >You then know this asm will appear somewhere in the compiler output for >this function. But where? In this example there is likely no other >code generated for this function (if you have optimisation enabled!), >but for any useful function, you do not know. > >(Btw, this is not an extended asm, this is a basic asm. If you use at >least one colon it is en extended asm, and then you need to write >"%%rip", i.e., two percent signs). > >> But if you really want to do this in an extended asm, then we would need to >> extend the asm syntax so that one can put CFI info in the middle of an >> asm. > >But what would the semantics of that be? You cannot control where in >the compiler output the asm will appear, or even if that is only once! >For example, in this code: > >int a, b; >void f(int x) >{ > if (x) > a++; > else > b++; > asm("beacon"); >} > >the asm is output twice, since in effect the compiler makes this > >int a, b; >void f(int x) >{ > if (x) { > a++; > asm("beacon"); > return; > } else { > b++; > asm("beacon"); > return; > } >} > >> One way to do that might be a special operator for formatting asm >> strings that only prints the string if we are emitting unwind info. We >> would have to find a free punctuation character that isn't already used by >> any existing port, and then assuming backquote is free we could do > >There are no free characters this way: some code out there might output >backticks in its inline asm. Everything not % (or {|} on some targets) >is emitted as-is (well, almost). > >> int main() { >> asm("`.cfi_undefined %rip`"); >> } >> and the backquotes then only print the string if we are emitting unwind >> info. Or alternatively make this a % operator like %`. > >Yes, that can work. But you still have all the other problems with >abusing asm like this :-/ > >> Either way, I >> think this would look funny, so might not be the best approach. It would >> likely be difficult for people to use. I seriously doubt many users can >> write CFI code and get it right. > >It often will depend on choices the compiler made, too, in which case 0 >users can get it right! They can get lucky, and sometimes it will do >what the user wanted. For my .cfi_* in inline asm problem, I have filed https://sourceware.org/bugzilla/show_bug.cgi?id=27472 gas: Suppress "CFI instruction used without previous .cfi_startproc" if .cfi_sections is empty https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99282 Emit .cfi_sections without arguments for -fno-asynchronous-unwind-tables (I noticed that LLVM integrated assembler did not support .cfi_sections with an empty section list. I just implemented it. )