From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 2DF6C3858D3C for ; Tue, 12 Oct 2021 19:13:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2DF6C3858D3C Received: from pps.filterd (m0187473.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19CIXd0Y035038 for ; Tue, 12 Oct 2021 15:13:55 -0400 Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0a-001b2d01.pphosted.com with ESMTP id 3bna5casq7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 12 Oct 2021 15:13:55 -0400 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 19CJ9Sgt026472 for ; Tue, 12 Oct 2021 19:13:48 GMT Received: from b03cxnp07028.gho.boulder.ibm.com (b03cxnp07028.gho.boulder.ibm.com [9.17.130.15]) by ppma02dal.us.ibm.com with ESMTP id 3bk2qbg7ag-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 12 Oct 2021 19:13:47 +0000 Received: from b03ledav001.gho.boulder.ibm.com (b03ledav001.gho.boulder.ibm.com [9.17.130.232]) by b03cxnp07028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 19CJDiDu12059138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Oct 2021 19:13:44 GMT Received: from b03ledav001.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3A1966E059; Tue, 12 Oct 2021 19:13:44 +0000 (GMT) Received: from b03ledav001.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E2B806E054; Tue, 12 Oct 2021 19:13:43 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.211.42.145]) by b03ledav001.gho.boulder.ibm.com (Postfix) with ESMTP; Tue, 12 Oct 2021 19:13:43 +0000 (GMT) Message-ID: <9bf3148807544fd7b83ec9334e9c18cf7b9bee81.camel@us.ibm.com> Subject: Re: [PATCH] Powerpc: Add support for openat and fstatat syscalls From: Carl Love To: will schmidt , Ulrich Weigand Cc: gdb-patches@sourceware.org, Rogerio Alves Date: Tue, 12 Oct 2021 12:13:43 -0700 In-Reply-To: References: <22a9ea816266f1b9e6948a396a1dc45cb5f8f153.camel@us.ibm.com> <287929e6460980eb4e0d12a52593689ebf4f309a.camel@us.ibm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-16.el8) X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: jZKUikC4hnDLHOi3q0z9yTGXSMjPgllE X-Proofpoint-GUID: jZKUikC4hnDLHOi3q0z9yTGXSMjPgllE Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-12_05,2021-10-12_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 lowpriorityscore=0 adultscore=0 impostorscore=0 mlxlogscore=999 suspectscore=0 priorityscore=1501 spamscore=0 malwarescore=0 phishscore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110120102 X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2021 19:13:57 -0000 Will: > > I changed the fstatat64 to newfstat. I re-ran the regression tests > > on > > a Power 9 system. The patch does seem to work correctly. Don't > > have > > a > > 32-bit system to verify on. > > So.. the regression tests passed with both fstatat64 and newfstat ? > That suggests there is not a significant difference between the two > syscalls, or this particular corner is not being tested. > It seemed weird to me that both work. I too was a bit puzzled and concerned by that. So I did some more digging .... I found the following web page that gives the syscall numbers on a number of platforms https://marcin.juszkiewicz.com.pl/download/tables/syscalls.html So as Ulrich said fstatat64 is listed for powerpc (32-bit) but not supported for powerpc64. The fstatat64 call maps to system call number 291. Looking at newfstatat in the table, it is defined on powerpc64 but not on powerpc (32-bit). It also maps to system call number 291. Clicking on newfstatat and fstatat64 in the left column takes us to the same man page for both system call names. The man pages says is: "The fstatat() system call is a more general interface for accessing file information which can still provide exactly the behavior of each of stat(), lstat(), and fstat()." So, it says to me that calling newfstatat for both, as Ulrich said, is fine. I do think this is all rather convoluted. I guess it is one of those things that evolved over time into something more convoulted and confusing then it should be. So as you said "...there is not a significant difference between the two syscalls". Carl