From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ln01.mxout.alfaservers.com (ln01.mxout.alfaservers.com [85.17.185.57]) by sourceware.org (Postfix) with ESMTPS id 2BA5D39DD41A for ; Thu, 12 Nov 2020 06:53:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2BA5D39DD41A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=blueice.be Authentication-Results: sourceware.org; spf=none smtp.mailfrom=henri.cloetens@blueice.be Received: from [193.121.150.145] (port=33500 helo=[192.168.178.60]) by ln01.alfaservers.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1kd6UJ-0007iv-5B for gcc-help@gcc.gnu.org; Thu, 12 Nov 2020 07:53:43 +0100 Subject: Re: When will gcc assign local variables to registers? To: gcc-help@gcc.gnu.org References: From: Henri Cloetens Message-ID: Date: Thu, 12 Nov 2020 07:54:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ln01.alfaservers.com X-AntiAbuse: Original Domain - gcc.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blueice.be X-Get-Message-Sender-Via: ln01.alfaservers.com: authenticated_id: henri.cloetens@blueice.be X-Authenticated-Sender: ln01.alfaservers.com: henri.cloetens@blueice.be X-Source: X-Source-Args: X-Source-Dir: X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00, DEAR_SOMETHING, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, 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: Thu, 12 Nov 2020 06:53:46 -0000 Dear Sir, What do you want to do ?. - Gcc, especially when the optimizers are turned on, heavily optimizes the source code.   If you want to reverse-engineer, in order to recognize the C-source in the assembly,   some suggestions: 1. Turn on the debug option. Then, GCC annotates the assembly introducing info as to which     assembly statement belongs to which source line. It may not work with the optimizer on. 2. Run the compiler with -fdump-all. Then, it outputs a lot of verbose files, documenting how     the compile and optimizations have been done. It includes all the restructuring, and also     the register allocation. Now, good luck with that, it are long and difficult to read files. Best Regards, Henri. On 11/12/20 6:04 AM, visitor x via Gcc-help wrote: > Thank you for the pointer. > > I learned SSA and realized that the problem is more challenging than I thought. As far, my understanding of SSA is that compilers restrict the definition site of each variable to only one by introducing phi-function and other tools. In this way it facilitates data flow analysis and further optimization such as dead code elimination. > > My idea before is to list all possible manners that compilers assign variables to registers, then it may be easier to recover variables from binary. Now it seems to be an impossible mission. So I rethink my ultimate goal, essentially a track to variable access sequence, which doesn’t require full decompilation (maybe). > > All we need to know is whether two instructions access the same variable (or say object if compilers care about only values). It sounds like an alias analysis in binary. Is it a specialized subfield in program/binary analysis? >