From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113374 invoked by alias); 11 Jan 2018 15:12:25 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 112654 invoked by uid 89); 11 Jan 2018 15:12:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy= X-HELO: mail.rt-rk.com Received: from mx2.rt-rk.com (HELO mail.rt-rk.com) (89.216.37.149) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 11 Jan 2018 15:12:22 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.rt-rk.com (Postfix) with ESMTP id 98C651A59AA; Thu, 11 Jan 2018 16:12:19 +0100 (CET) Received: from [10.10.13.119] (rtrkw512-lin.domain.local [10.10.13.119]) by mail.rt-rk.com (Postfix) with ESMTPSA id 7EE591A59A8; Thu, 11 Jan 2018 16:12:19 +0100 (CET) Subject: Re: [PING][PATCH] Fix for prologue processing on PowerPC To: Pedro Franco de Carvalho , Kevin Buettner Cc: gdb-patches@sourceware.org, "Ananthakrishna Sowda (asowda)" , "Ivan Baev (ibaev)" , 'Nemanja Popov' , Djordje Todorovic , Ulrich.Weigand@de.ibm.com References: <20171108095850.394a48ca@pinnacle.lan> <8bf0014c-e83c-5988-4d06-173572f21186@rt-rk.com> <7ba16b14-9384-34d9-937e-531a2192842a@linux.vnet.ibm.com> <87608p4dgr.fsf@linux.vnet.ibm.com> <87r2qx4oit.fsf@linux.vnet.ibm.com> From: Nikola Prica Message-ID: <20038806-69e5-b7ce-479b-54185089145b@rt-rk.com> Date: Thu, 11 Jan 2018 15:12:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <87r2qx4oit.fsf@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-01/txt/msg00214.txt.bz2 Hi Pedro, I understand it now. Thank you for explanation. > I'm just not sure that the bitwise operations with > lr_reg are safe considering it is an int (e.g., is lr_reg | 0x90010000 > well-defined?). > Regarding that lr_reg is changed to valid value only when it is previously set -1 and that it is changed like lr_reg = (op & 0x03e00000) it means that it only takes bits between 21-26. I would say that it is safe. I suppose that it is set to int for easier way of verifying its validity. Thanks, Nikola Prica