From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 8FnRACSMbmO6NxcAWB0awg (envelope-from ) for ; Fri, 11 Nov 2022 12:53:40 -0500 Received: by simark.ca (Postfix, from userid 112) id EAC1C1E124; Fri, 11 Nov 2022 12:53:39 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=GFB1m/MH; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RDNS_NONE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (unknown [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 44E4B1E11E for ; Fri, 11 Nov 2022 12:53:39 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DCC0A3857838 for ; Fri, 11 Nov 2022 17:53:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DCC0A3857838 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1668189208; bh=/8Bg/obLK3jmd3it1etXJ+XlKpTAIF3CAr/slKZ/G74=; h=To:CC:Subject:Date:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=GFB1m/MHS+ThEbEdvsq+80n5wnycscpKS87cm+cUzXJlwllIOZQA5xcgRU9hQs/1Q FG/SC4+OCecksZuC9lRjFkfhuLIDbhbjbLxXrZ2yiJtx2HEduwcc6SAh+4dI+kMuAe s+NvE7C4n/ZuAi4KT4IGhXO7kVzWuUPxcpQGv79Y= Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id CB6B83858C29 for ; Fri, 11 Nov 2022 17:53:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CB6B83858C29 Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 2ABHi935027444; Fri, 11 Nov 2022 17:53:05 GMT Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2168.outbound.protection.outlook.com [104.47.57.168]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3ksu1y86b5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Nov 2022 17:53:05 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GPl9YdKEOMkP5o61BgD7BCUg6WeH+Vxdp8JYM1jCmM7rzhVmY/5go8K56oKP4vKSKe7gQiG2K4QB9mHrwQWBf1+QN6YCJ+mmnJoUdlhprq/ZewXqR8Qt+t/O/JWxQCKjbxdfLLa1rvgVC+j3N+qrzH5hmsIWY8v/dM7dmF2ZVRQyndmwY0nvKkO4C2WPQgPl1i58Fc9CBtIt2EsAPYSWkCPABjES3gNmpA4FmqYNwpybVCGB5Om8ehPtj5T2oBEG8URezpJipuPJRnKYRknLN3Y5ekS03knKizvq8tLx8I3FqO3pGHtaKm4DuDVBNU4TbZcz2UoNpXpHP9sh4uBciw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=O/sazmxLLyRvUt61m6h9sWUpiLin0B4dhUXyKG0xfuk=; b=mjHs31Zhi5stijo/ACFW9Oi3/94eKtO+4sgiPBQKa3+NH9UULVwwVoa/k0rL9MrZY8Q/SNWDNXuy9B4V06NqtKnZ0uSqikXBAuQazWZBHFSVXfDkqMXYknAkk0fJQAsFlLFxfNRtraacAuRNMSnJhNMkRHruwuhtwjVTeSWJNHvW0oWl2C3j/FiH5R9hDr3jM60nIzNTM4618mYfOwvqgNZnx4d1fIBk5eREaArvn4yqdJWS7ufaHoGvz97DJKX9E4S4Jh5Enjtl10VFhfvc+1xDHgZgyj7GD0EDhVnTEYd+RiiYEu1p4ldH8rOIQYrVCxeiv7Q7I4Vcbw6fJndMsg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ibm.com; dmarc=pass action=none header.from=ibm.com; dkim=pass header.d=ibm.com; arc=none Received: from BY5PR15MB3540.namprd15.prod.outlook.com (2603:10b6:a03:1b6::29) by BYAPR15MB3430.namprd15.prod.outlook.com (2603:10b6:a03:107::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5791.25; Fri, 11 Nov 2022 17:53:02 +0000 Received: from BY5PR15MB3540.namprd15.prod.outlook.com ([fe80::a9e0:881a:895f:5fb9]) by BY5PR15MB3540.namprd15.prod.outlook.com ([fe80::a9e0:881a:895f:5fb9%4]) with mapi id 15.20.5813.013; Fri, 11 Nov 2022 17:53:01 +0000 To: Ulrich Weigand , "gdb-patches@sourceware.org" , "simon.marchi@efficios.com" CC: Sangamesh Mallayya Subject: Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX Thread-Topic: [PATCH] Fix call functions command bug in 64-bit programs for AIX Thread-Index: AQHY8o8oLBa0QEnD0kK130AZD8l+9K41B4CAgAT1XL8= Date: Fri, 11 Nov 2022 17:53:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: BY5PR15MB3540:EE_|BYAPR15MB3430:EE_ x-ms-office365-filtering-correlation-id: 096362ad-d87a-47fc-9b9b-08dac40d93ce x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FaOmdl2M2+/sVpB1R/+fuPa7lWJbHpCfiylNJ6udg+xas9KzSy6sVd067lAs5lvIc2p206/fdZOgFt+VeqCzbyt7Bf5rCVbV9+pmX+rPeeW3FK69wPsklLG9kFpr8eMNY6SpvPYdYbbO4dAuqDDwFQPdbqhs0jaZuRgxfmknD8dtx65gaF0sevgJdgeWupEjRW4MI2JP1Sl2fqB9IdpXnulTewPawY+IVaOYfdpmnhyFL5e25XctcADQBd1JIOSrElNacI/6rLMF0QB67chIOYb5TQDHJraGYSrWLZJHe/wOJIqquKGL1wmrvg/MAss3l5rDx6RrFWvfBmNfkAh3j8R5GW4Uw69zI+Hm7Guj+Fl7FTVUc84Ry9EWrQ/XaM3gk/iKLhN9f+1/GprIlLfVxqQnMVsjTr3gmhCOiPGv9DAKPRGTxDgFVYd22qLReiKIpTO1DQfn1niy8G9HKdVMPsu8GgWUq4SUqR7t+9eXGDCQz6Wgi5Fe+u4LsbmogArZj+sZ33+nd15c1vZ1lZ4vgZ6EBfhiq5FGjGN4ccYoBs1pHTWMit0kMKlUyrmzCo39cIuzuKvXyQjr+buqY7yFsYi+pl3sYqvn0CaSzFlSwjsE03Impxi7JxO+kitVn0MLNpi8kJM1G7dCI8R+gBDxGpaTPShwgbOSpUfuHojNnYmpcrgpga4+k4E0Gdcu5eLAgTUI9JX3ig96RTxOgX8fRiityFLT+jqD5fDGRYlq0GTpxzOWuGZVC8ClNi8rPs9Rvc83HFBF/Fpd8xj1BS0NrA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR15MB3540.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(366004)(396003)(136003)(376002)(39860400002)(346002)(451199015)(38070700005)(19627405001)(8936002)(41300700001)(5660300002)(9686003)(8676002)(4326008)(64756008)(86362001)(2906002)(110136005)(66446008)(316002)(66476007)(91956017)(71200400001)(76116006)(66946007)(478600001)(186003)(33656002)(53546011)(52536014)(83380400001)(38100700002)(66556008)(55016003)(7696005)(6506007)(122000001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?6I8G27W0lG+AJPaSRlZjfyv/MRrazXPa1CWh93n78Xp7RyP1ItRZONrVcfBU?= =?us-ascii?Q?9EVAh9gU1Vyk0/8FwGwXTTXCNIVtriWuFcjyc0I+3vyKGbK+/nhY3mNdaT01?= =?us-ascii?Q?pGMRN5KKwX7OK+bqjwuIAcGWRAfJ+jxgyyaKLtMJAnmWgUILnlQHYI89eQWI?= =?us-ascii?Q?RWjSS3UzClgv+S1phPoxQm9cp6D4uaHgkirA5zNp/5ophQta4S0Emmn5uuiy?= =?us-ascii?Q?urHK6uv9Sk7ixcE+dPxJdeG4SviF/L9CpCKko4QGnyPzWqx+/OWC2sbNOhcx?= =?us-ascii?Q?oYUsCgfb6mCIw1SzU+wErKnC2oxuOG1dEsZVyaOP/KYs5VS3pBTI5jKDLp6d?= =?us-ascii?Q?nIbMUlfQKeFlXVRBScKcvMf28pNgmSw1fK3E8CgCWqQPkkcsNtzfYjoIdAZ/?= =?us-ascii?Q?NaQ1m/AyP91AvfJo1hSuHXJkCND4jStU04M/pAgW32IJCsYe+qKLpBt17IPs?= =?us-ascii?Q?MiLThAAfKvfwWzFx1nm3iILlI0H4wfHDuuPKwcRuIGyYbFbuD8jn0FCrVTTj?= =?us-ascii?Q?e65VEpyrczibVWA+ObGhX5edqiGB75XsXJqCo4yBbDCMOyXiMre5Dmuz2AmH?= =?us-ascii?Q?3nYbBdN21DTn44VIcyF4/hslMOqBuEf8LO8+wykVKxgGvGMHA7AOiU69XcnB?= =?us-ascii?Q?RzZVfolkmuJfeo6jT3aOb3xMXT3YFYaKUO1hHQ04y0V7HnE5Xban+fVth+fS?= =?us-ascii?Q?Hpayf+elr1zQsyipSIPGYM/A82rnZBtLP3h7Zk8iQJIsSlHCUyZ+xCE6tHb4?= =?us-ascii?Q?HZg4GT2FnvgbGbK+0TLicByTM8/M02Qn7G0L+1SKsYmaX/iHEzBOF9HkXAm8?= =?us-ascii?Q?hpp8Uvke+PbJtuLftz2z+BnX8Ini1xY2r5nCN1LgZ/CyuZpmGzGbGMOy3WnL?= =?us-ascii?Q?gBzhxk+IwOcJuCpYiWB8pDicbTAbeGmWpQRE6xC3dNnfdN6UxvNIE4v2WJhk?= =?us-ascii?Q?Z+w7WCVGZ3Dh0DNs+J7U65PFwmpzk/sXae4I1N2P4Dr+l6rwHF5vVxPu73HP?= =?us-ascii?Q?FfAC3TuezyIm1zxAYYsY7oYHfyTpZQjOPukW1hJaK9jAAXIfPnjpkRSLPf/Z?= =?us-ascii?Q?HzBGh4/cZohsId7pMsgJgmTcfdxiiA6QpjS5aE/IOjtPFZO1BajPjO1YCVKM?= =?us-ascii?Q?lT0HalD5YqONX7Jv9equvKHmamQpeN25W1Y5OxbnoXkIpYNyktR/52xb+2XR?= =?us-ascii?Q?6RJLUjBV7gaC3xLByJJTI7LebHKtsJSVF67t2ivhd2cJ+yRE/ZvgP9qUiW0j?= =?us-ascii?Q?wGpXFF03xdlFq1P52ELqa5I/p9UylHMv3YBdtDXbxSvPt/tpJPRo7Qo7UMaz?= =?us-ascii?Q?BGoFJFD0ZXSg0kWHu46L4qy/gP0BzIIu6ayIKRTvGx/9wEcNcB1QquxCFbKg?= =?us-ascii?Q?aMn9aCr6Wn0HUjnBYvM6jGdPIC10WikEPW9H0l6EVIimjUwGDWv+18/vlcCh?= =?us-ascii?Q?mZEJ16j4iLEJmEbKHgOb+A4QaqgJMla1Al6SXBu89CwPTBNeUkkXufNXyuq1?= =?us-ascii?Q?tLPYwK2uHxAGgP6KJGGCm7zgjaIVtQ7z7enUcbX+Fa7DI6TKQVgq+Bzx+cPX?= =?us-ascii?Q?n9f8J/73oT4X0RB8OFpjk4IaNshT8lpbBUp47Rh+NUZA+f2ifGzCuitAKhMC?= =?us-ascii?Q?iKtFBbLYr+kOknaF42g4/VBQE2gCC01MVt7kaVhadAgP?= MIME-Version: 1.0 X-OriginatorOrg: ibm.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR15MB3540.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 096362ad-d87a-47fc-9b9b-08dac40d93ce X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2022 17:53:01.9443 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fcf67057-50c9-4ad4-98f3-ffca64add9e9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nIZQ8lX7Vs6/IYCkxdBiJ9MobM+ipJ0kSC1o7UoqtYxPblrCQyal6e9BtluxMeM3d62EulcaMjoIWw76p/SoAQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB3430 X-Proofpoint-GUID: lKY3tMm4_ipPT9qNE9sqqk32iCTrcLNO X-Proofpoint-ORIG-GUID: lKY3tMm4_ipPT9qNE9sqqk32iCTrcLNO X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-11_08,2022-11-11_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 malwarescore=0 impostorscore=0 lowpriorityscore=0 adultscore=0 mlxlogscore=903 bulkscore=0 priorityscore=1501 phishscore=0 suspectscore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211110118 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: , From: Aditya Kamath1 via Gdb-patches Reply-To: Aditya Kamath1 Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Hi Ulrich, > This is not how the GDB register cache is working. Can you explain in > more detail what exactly you're refering to here? Let us say we have a simple function, like print_Num (int a, long b) which = prints these numbers a and b and the program is in 64-bit mode. If the prog= rams are debugged normally, things work fine. But if a user attempts to see= what the function does with the command call print_Num (int a, long b) the= n in the register assigned for function parameters the value 0 is getting d= umped. What is happening is the pointer that is pointing to the input numbe= rs a and b in the regcache->raw_supply which was addr previously is not ali= ging our values. It dumps the higher 32 bits in lower 32 bits and lower 32 = bits to the higher which I figured out when I extracted it byte by byte usi= ng long pointer [long addr64 variable in the patch]. If int pointer is used= in 64-bit mode in raw_supply code's second parameter, then memcpy () befor= e rs6000_ptrace64 () fails to copy the right 8 bytes in buffer as int addr[= 64] is pointing to the wrong information. Overall, we were not pointing to = the right place with the pointers passed to these functions. >- what does ARCH64() return? True in 64 bit mode and false in 32 bit mode > - what does register_size(...) return for those registers? 8 in 64 bit mode, 4 in 32 bit mode (for GPRs with a 64-bit inferior it should return 8, if it doesn't that's probably the root cause of the problem) > - what value does ptrace return in your case? It returns the data parameter value that is passed as the calls are success= ful. Consider this code below:- #include "stdio.h" int num2print(long num, float num2, int num3, double num4) { if (num =3D=3D 0) { printf("R0\n"); return 0; } if (num =3D=3D 1) { printf("R1\n"); return 1; } printf("R%d\n",num); printf("R%f\n",num2); printf("R%d\n",num3); printf("R%lf\n",num4); return num; } int main(int argc, char** argv) { printf("Hi Bangalore %x\n",num2print(27, 16, 13, 9.9)); return 0; } The output before patch in 64 bit mode is:- Reading symbols from /home/XYZ... (gdb) b main Breakpoint 1 at 0x100007dc: file /home/XYZ.c, line 22. (gdb) r Starting program: /home/XYZ BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for sto= rage class 0x2 BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for sto= rage class 0x6b Breakpoint 1, main (argc=3D1, argv=3D0xffffffffffffad0) at /home/XYZ.c:22 22 printf("Hi Bangalore %x\n",num2print(27, 16, 13, 9.9)); (gdb) call num2print $1 =3D {int (long, float, int, double)} 0x1000006a0 (gdb) call num2print (2, 3, 4, 5) R2 R3.000000 R0 R5.000000 $2 =3D 2 (gdb) The output highlighted in bold should have been R4 but is R0.. The datatype= of the variable is long and if you print the output byte by byte before me= mcpy and if you have taken a long pointer to raw_supply, one realises 4 whi= ch is lower 32 bits is in higher bits and 0 in higher bits is in lower bits= which was the pointer will be holding. The pointer getting the value in ra= w_supply was pointing to elsewhere instead of 4 [ the lower bits] if it is = an int pointer. Kindly let me know if you need more details. I am only trying to re align t= o correct the things my pointer in raw_supply function has messed up. Let m= e know if there can be a better way you have in mind. Have a nice day. Thanks and regards, Aditya. ________________________________ From: Ulrich Weigand Sent: 08 November 2022 19:00 To: gdb-patches@sourceware.org ; Aditya Kamath1= ; simon.marchi@efficios.com Cc: Sangamesh Mallayya Subject: Re: [PATCH] Fix call functions command bug in 64-bit programs for = AIX Aditya Kamath1 wrote: >The issue is that when a user attempts to test the return type or print >statements via the call "FUNC_NAME (parameter A, parameter B)" command, any input be it parameter A or B is taken in little endian format from >the GDB cache. But AIX is using Big endian format. >For example, if we have a value 21 as type long then the higher 32 bits >[ which is 0 in number 21] were stored in lower 32 bits and lower 32 bits >[ represent 21 in the number 21] is stored in higher 32 bits. This is not how the GDB register cache is working. Can you explain in more detail what exactly you're refering to here? The register cache holds a sequence of bytes for each register. The number of bytes in the cache depends on the size of that register as defined by the architecture. The contents of those bytes are *always* assumed to be in big-endian byte order on AIX. For 64-bit inferior processes, GDB assumes that the ptrace call always uses a 64-bit buffer, even if the register size is only 4. To handle these cases, the current code will convert between the two formats, which looks correct to me: in the fetch_register case, it will retrieve an 8-byte value from ptrace, convert that value (correctly, also for big-endian) to an 4-byte value, and pass that 4-byte value to raw_supply, which should expect 4 bytes in this case because the register_size is 4. To understand what's going on exactly I need more details: - what does ARCH64() return? - what does register_size(...) return for those registers? (for GPRs with a 64-bit inferior it should return 8, if it doesn't that's probably the root cause of the problem) - what value does ptrace return in your case? In any case, explicitly listing specific register numbers by ABI is definitely wrong here. This routine must correctly handle any register, it does not matter what the ABI usage is. Bye, Ulrich