From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) by sourceware.org (Postfix) with ESMTPS id E69663857001 for ; Tue, 15 Sep 2020 11:59:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E69663857001 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 08FBoIsE148983; Tue, 15 Sep 2020 11:59:42 GMT Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 33j91de2h2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 15 Sep 2020 11:59:42 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 08FBnvIu154279; Tue, 15 Sep 2020 11:57:41 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 33h7wny44b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 15 Sep 2020 11:57:41 +0000 Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 08FBveUt017119; Tue, 15 Sep 2020 11:57:40 GMT Received: from termi.oracle.com (/10.175.14.173) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 15 Sep 2020 11:57:40 +0000 From: "Jose E. Marchesi" To: Nick Clifton Cc: Nick Clifton via Binutils , David Faust Subject: Re: Commit: Gas: Add .nop directive. References: <87d02oe6h4.fsf@redhat.com> <87bli89y63.fsf@oracle.com> <66993ade-f84c-5f7a-86e8-a1dd017f38b5@redhat.com> Date: Tue, 15 Sep 2020 13:57:35 +0200 In-Reply-To: <66993ade-f84c-5f7a-86e8-a1dd017f38b5@redhat.com> (Nick Clifton's message of "Tue, 15 Sep 2020 12:13:06 +0100") Message-ID: <87pn6n5k28.fsf@oracle.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9744 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 adultscore=0 bulkscore=0 phishscore=0 mlxlogscore=744 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009150103 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9744 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 impostorscore=0 priorityscore=1501 malwarescore=0 suspectscore=0 mlxlogscore=764 clxscore=1015 adultscore=0 lowpriorityscore=0 spamscore=0 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009150103 X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2020 11:59:47 -0000 >> In the same spirit, it would be awesome to be able to generate >> architecture-neutral data directives as well, for DWARF and CTF and the >> like :) > > What about ".dc.b " ? Does that not work for all targets ? Maybe it does. We found problems while trying to have .s files in CTF tests in ld, generated with a patched GCC: the data directives emitted by the compiler are architecture-specific. I think the GDB testsuite ships with a DWARF assembler because of the same reason. So I guess the problem is more a compiler one... i.e. what data directives it uses. >>> +#define md_single_noop_insn "mov %r1,%r1" >> >> For BPF we have this in GCC: >> >> (define_insn "nop" >> [(const_int 0)] >> "" >> "mov\t%%r0,%%r0" > >> I think it would be good to settle on the same way to encode nops in >> both GCC and binutils. > > Actually David Faust just posted a patch to change the instruction to "ja 0" > as this is what the kernel expects. I have applied his patch to gas. Maybe > gcc should be updated as well ? Yeah, actually it was your patch that prompted us to revisit the NOP situation in BPF, and we found out the kernel actually expects a particular encoding for them. So thanks for that :) We fixed GCC as well.