From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id A8C0B3858416 for ; Mon, 14 Nov 2022 17:32:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A8C0B3858416 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ibm.com Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.19/8.17.1.5) with ESMTP id 2AEGTQmS013772; Mon, 14 Nov 2022 17:32:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=pp1; bh=u8bILYh4sSqZKETSDmvoM8Qk/szLYd9JJjbK3abSWck=; b=OuWdlRagyYhJi8blfN2nkSlAIx/Nl7FBNn5kAC7IIPt0KygRTopsEEZ+4bzeZ54OlA4I WLeFoRftZZ/nhibzEqHfUw2s+q/P18kxxls4llWYricW2qcAQVSoF2ER0BaoRplTDA3g BJOiyunR6gh2jQsAFKXYEO9Y8DOXJMJDOEho0UlYSbyvCqp1h9x3YnenuJMeaBqKmKkv TWv33/OQFqn8TMZ5u4Y6Yj7yAktUR3GEDTqLYx1KqCs5pfpgK4Nl0Cv2ccNypqGGnPUS 14hc0YeBoasot2Al4Db1RnET1QlG/JJJMuE/IWtAdHCH5ktg8aN1s0jnwQMpadCt+giE pQ== Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2173.outbound.protection.outlook.com [104.47.56.173]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3kus88hkbt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Nov 2022 17:32:31 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mwvCPADPjcZlvHyMq6zpUaFab/IgNLwO5+7kGDaRtBsXRqNFUaF8ITolqgyj1MO2/jKyiYYFUddXBpRnkTD5HbarHPfmBBAl4ELa+e1dgmPs/UK8pNXw4+ENUMxkyPu7HJNctZhkKxvIgTLqVAiMEHQ2gE4/8Nn8ag9FE+kqCQS/dfzu32rfdKH30KTXnmYRWfPZd5TThmJXSrwl+5P8bgM4CTJi3v9lRWOsc5LJ+QL7pgnPPRcb8h7qhaofJ4kgx6iwCyvr24gphnRAyhj9cXzFsA6A4x7UWXxQ7UiSUtTT1c7gTrQEYbXvLy2QWXl5Rq3paCFZqrpHe/0dTr2rWw== 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=u8bILYh4sSqZKETSDmvoM8Qk/szLYd9JJjbK3abSWck=; b=dVgZjyf8S8GAG3iwt0wqlykRdQOkAiP9A8/pJ3zM52Knccumwes3QxKbW8StgzBZ/KcCROucmz1T0Qsfngrpc2XvrcHzrmg/wfWUjUEISCevm0aMmvhc2c5AHvhYuEMn5UwF5J2oij3e0BQs+QNhm2Mops8aV+13qEl1K6+rrpfokp+7FmaTQP/BGs3ZVv5oxdEtiyYYywJm5DrwiKL3Nb4U9kf54TdPDnwd2YwMNgaPlIwZQGEgX7f80bol8q3We5Ub8YtX3kn5d1QgxPoIt7iS8r0ETyM8vRyH0cr4VeNEaB9xpr3SUysLQj1Y64s0p2dQ0QwKmjagltaCyozPhA== 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 PH0PR15MB4720.namprd15.prod.outlook.com (2603:10b6:510:9a::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.13; Mon, 14 Nov 2022 17:32:28 +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; Mon, 14 Nov 2022 17:32:28 +0000 From: Aditya Kamath1 To: Ulrich Weigand , "gdb-patches@sourceware.org" , "simon.marchi@efficios.com" CC: Sangamesh Mallayya , Sanket Rathi 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+9K41B4CAgAT1XL+ABKCogIAAGRWB Date: Mon, 14 Nov 2022 17:32:28 +0000 Message-ID: References: <049a54779f7280ddef6c2da12d0714023514dc9b.camel@de.ibm.com> In-Reply-To: <049a54779f7280ddef6c2da12d0714023514dc9b.camel@de.ibm.com> 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_|PH0PR15MB4720:EE_ x-ms-office365-filtering-correlation-id: 65feaf62-0e7e-4feb-be63-08dac6663406 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VtVgotYJDer4A9wyVM/oryk1ePcVUcZ8i5EogaIE86p8PGCEs/xRpwu/uxttLs0oF6Ev4bDDPeagUnoTjALWD0vZ6JBWcRrmY7trsHJhtOIFV5K5RHLuAHV+jJTDgA/f0dSOEgGZF5DwbpiUf8Tz46NrV0esF54cNw7qPPVT0HykwgfRtMONU+kI0Wzy1ia6C+XXhc3s+6OgIzYfuC4Ru/+inivmWquZqVDXHC36KcKg1EXPKdsnNDEeRyO2d4vGU8ryyuvw37OJZFyb8erLsGXO+FH1GMLUWeBx+yv2Ls9czBfoBkbDA7uBPwN9k6pQygKi/Hrirpnk6GmeUAMjug66SGT1okPORqyFKL5UbTBzwhbu7lmVn4Xr2k5oUksreNRrNm9Bw0zEKPHrbgMJ3zXFUk3M61ae3r+R/YWAfxZ55gLRvpUQJl4FagOvp84CV75EGnBnOKF5DztZwvb5wFujIbhRBlbHXH7+WD3Jg4yAfSQBR5Uugc7laAzx/tOwSEWiqjjiRFS2hqG7IMwwr2iQv7gt87Ch5BWvWAtdnplvp/i0LZSw5+k8RlDn1Wwb0FAyGLyyQWcgoRNUbQtUQKTS7iNjluFnqycfcX/Y5i1mSStaNCyS6si+ANopFKTCJUU1gZAzmqN+rnJNQDYIl+yYztfxbn02l3FgTdcjuMVKxZJXl8W1jgMdK0ScErAlyhivoAf0YP7ec17lFaIe+0FRTPeQyNhagVppdH9bXV0xOD4ZAyaehs79fOTLQeLCBafrvEIxok6r1d28g1cjQg== 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)(376002)(39860400002)(136003)(346002)(396003)(451199015)(8676002)(66946007)(4326008)(66556008)(54906003)(66446008)(66476007)(110136005)(76116006)(316002)(91956017)(186003)(64756008)(19627405001)(2906002)(33656002)(8936002)(5660300002)(52536014)(41300700001)(71200400001)(478600001)(55016003)(6506007)(86362001)(53546011)(7696005)(9686003)(38070700005)(38100700002)(83380400001)(122000001)(579004)(559001);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?A+RZEdwB9Vn6eawRtCKB+8teAjnqLud9AYDWBMAkcC6HpUdBIvCWF+rO+HL+?= =?us-ascii?Q?7JTWYUPfEoVDPvv8sgccY4w2SXhw9s0Ux7Wc3FMSoB7o5+3Zmy2VM/759xWb?= =?us-ascii?Q?qKoxK6emzq8FOurBSjFTjv1miDiQCuGHr43U2Dwcu6reaQEZidrekvcMKXSA?= =?us-ascii?Q?DyGr1fdw47w9i76qhc2A52i0nSNQZg4++vjaCLvpP0IOENrQsc1qEyjT0okT?= =?us-ascii?Q?l1vS+no7KABkKRJYWLzPHlfA97VcJc1oq5hTuRdz3AV8+RZdFhc8/sqMXoMj?= =?us-ascii?Q?M94Xpzn/Sn2+yWe866SWuVgSoe7GqaZLbT8IZQ99BcWqKj0d8p9QDcGppBDq?= =?us-ascii?Q?Fny+IJSUTl8W0iN221Kw6o2W+tjyZTM059NYpNuSVHb8rWTxF19RLJ/wfykY?= =?us-ascii?Q?Ao6kylVMOjBQrX0oCOOWmx65WRRILRPX9VPP7+BAJSymHsJ9pFukGWlLknfo?= =?us-ascii?Q?2TAqxlqx29QnukWsq4Wued9pLRkZSYnuU/XnLqnWUwmybSsXbufSIGEz47dT?= =?us-ascii?Q?BMwifCSzmDSYOz+chhXyuTFlZyhY2Czf7pY0PuUTzwqJce2oQI+GWE2nINh/?= =?us-ascii?Q?J5I6muSKFgh6BXSlk61LIc+xYbVEPBmfsKpnCwnTRsXkrcBCET8paXXOdkdi?= =?us-ascii?Q?qVlXGch+/1pmfygiH3dJtH9IP+AYXv+aLQqso9gfSyaqWKQ2FvIaluEfdQjZ?= =?us-ascii?Q?IcizDixT9Ip1bIMYBUfm/rzeQEVY5bGGwQ6SEd3L74aER8t5i5vzoqj8e9D5?= =?us-ascii?Q?2C6GjDC3XtKSLWMt1qr8w06Qt98mb02M9tuULrmE/FWYdEOa9dotDVOxTQel?= =?us-ascii?Q?pj78c6NGqLCDuBwAQ26atAjOHRBwzRNN4SkWlPJIokabzaJaM5ZbzgmKvP9G?= =?us-ascii?Q?PWYHqR2WtT/ZLvAmyEEAoAXXrS/N4KLTV73rQ/jb5kOREM3I/06oQ2kcUJZ5?= =?us-ascii?Q?nim3vW1IY0awPZu+TECnIIQF44TlvEe+k7gy6cBcGHdwx9msQ9o8cmmcT0Kh?= =?us-ascii?Q?Q258Hg4p2y6pkgaYhrKqW5yIcT7sQRSYxPU96OfWOnk0CkuR69Oztc2HHdfr?= =?us-ascii?Q?9lTMUDL4Dpbb9fgaFViiz3DsZJfmPzS4Nw7uqT8Nk7RgZ3fv/pfHFuQcyCii?= =?us-ascii?Q?j0ZppoHNID6VuXPM6H+5dkWN0NGLoqbfltfUaDpYetytf1LYs5U8mV/2iAUh?= =?us-ascii?Q?OkEP0ArdK3Vsoi5bbIj/a42hu/4Ck9t3WmcXLTlBEeR7L9IUa4Ao9un+ZWq2?= =?us-ascii?Q?yai6EP48cHW5bmMczv94zgxCCJ4WSpWzVFQOJxOpj6S9Q99tUPTLCVzJeazv?= =?us-ascii?Q?CfizSWZ38vfVuv+sWWfxYQXFYxo+R9LnIlq8GU0U4bLI9dIU0kNQOvElRVxi?= =?us-ascii?Q?C3Rc+L9UY1sE5uu+9yAidY89K1Hg7xMsbUGNFBilTDJhQpeC8gEHNqsRzyYX?= =?us-ascii?Q?cc7eSAgJ+h8G3wEpq/eEwhKLmW18bkdJBWMiFWP3cffhFsdp2qcARAl+aXsw?= =?us-ascii?Q?YiSv1rC5HOKvyVZvGK8m6okET+3yegcT8naJXFlXJTXqdbMtAyKrKao8lhej?= =?us-ascii?Q?Cj8IWtVj4pTl/QY1WngmRvDqQosOvUWdOA80B5VHYco/e1CB5JDJ/WAccS+c?= =?us-ascii?Q?4GbWG7XgmZqhi3jIaWcvptGACATh1TU76YT7p/q89D9J?= Content-Type: multipart/alternative; boundary="_000_BY5PR15MB3540177BE8045318983CE968D6059BY5PR15MB3540namp_" 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: 65feaf62-0e7e-4feb-be63-08dac6663406 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2022 17:32:28.7542 (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: nCaI8vMLLGBcHA7yaYcPKcnoZ/NvdcO66ldmm1PUPtp7wa1rGQx24/qtba/awCzY1kf39v5wPjNFniiOYeox5w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR15MB4720 X-Proofpoint-ORIG-GUID: -Dsv0kjXq73IVYTcR3YgvuKW8vq5Xy-d X-Proofpoint-GUID: -Dsv0kjXq73IVYTcR3YgvuKW8vq5Xy-d 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-14_12,2022-11-11_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 mlxscore=0 mlxlogscore=726 spamscore=0 impostorscore=0 phishscore=0 clxscore=1015 suspectscore=0 priorityscore=1501 lowpriorityscore=0 adultscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211140117 X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --_000_BY5PR15MB3540177BE8045318983CE968D6059BY5PR15MB3540namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ulrich, >Did you actually verify any of this information? >I.e. by debugging GDB itself, or by adding debug print >statements to store_register? >I'm asking because if the above is all true, then your patch >to store_register is a complete no-op for this case: I understand. No problem. Let me make it easier. So, consider a program wit= h a function num2print () which print the number we pass prefixed with a R.= For example, if we pass 2, it prints R2, 3 it will print R3. Please find t= he program at the bottom of this email. I have added a print statement for what we get in *addr via raw_supply and = what we copy in long buf that will go in the ptrace. Also, I print the regn= o. As a fact register number R3 to R10 are reserved for function parameters. So, the GDB output for the program below is as follows:_ (gdb) b main Breakpoint 1 at 0x100007e4: file /home/XYZ/gdb_tests.c, line 22. (gdb) r Starting program: /home/XYZ/gdb_tests 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/gdb_tests:22 22 printf("Hi Bangalore %x\n",num2print(27, 16, 13, 9.9)); (gdb) call num2print $1 =3D {int (int, float, int, int)} 0x1000006a0 (gdb) call num2print (2, 3, 4, 5) val in regno 3 via buf is 0 and *addr is 2 val in regno 4 via buf is 0 and *addr is 1077936128 val in regno 5 via buf is 0 and *addr is 4 val in regno 6 via buf is 0 and *addr is 5 val in regno 1 via buf is -1696 and *addr is 268435455 val in regno 67 via buf is 1152 and *addr is 1 R0 $2 =3D 0 (gdb) info reg r0 0x1000004f4 4294968564 r1 0xffffffffffff9e0 1152921504606845408 r2 0x1100002e0 4563403488 r3 0x1 1 r4 0xffffffffffffad0 1152921504606845648 r5 0xffffffffffffae0 1152921504606845664 r6 0x800000000000d032 9223372036854829106 r7 0xfffffffffffffe0 1152921504606846944 r8 0x0 0 r9 0x1 1 r10 0x0 0 r11 0x1030 4144 r12 0xf1000600005901d8 17365886760216232408 r13 0xbadc0ffee0ddf00d 13464654573299691533 Clearly from the GDB output the buffer value getting copied is 0 but *addr = is 2.. So memcpy (&buf, addr, 8); has not copied the values properly and hence we don't get the desired value= .. Kindly note these programs are run-in 64-bit mode only and in 32-bit mod= e we are good. Now let's change the case. Let's make one of the parameters in the num2prin= t function as long. The output for the same is as below in 64-bit mode.. (gdb) b main Breakpoint 1 at 0x100007dc: file /home/XYZ/gdb_tests.c, line 22. (gdb) r Starting program: /home/XYZ/gdb_tests 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/gdb_tests.c:22 22 printf("Hi Bangalore %x\n",num2print(27, 16, 13, 9.9)); (gdb) call num2print $1 =3D {int (long, float, int, int)} 0x1000006a0 (gdb) call num2print (2, 3, 4, 5) val in regno 3 via buf is 2 and *addr is 0 val in regno 4 via buf is 0 and *addr is 1077936128 val in regno 5 via buf is 0 and *addr is 4 val in regno 6 via buf is 0 and *addr is 5 R2 R3.000000 R0 R0 $2 =3D 2 So, my first parameter is long, and rest are int, except the second.. Check= this out.. The first parameter is pointing to 0 in *addr but is copied properly in buf= which long and is 2.. This is beause *addr is pointing to higher 32 bits 0= and lower is 2 but somehow memcpy copied properly into the buf. Our integer friends in regno 5 and 6 [parameter 3 and 4] are taken correct= ly in *addr but is horribly wrong after memcpy and what goes in buf.. So, the conclusions are long is fine, but int are gone for a toss. Also not= e our *addr is int.. (gdb) info reg r0 0x1000004f4 4294968564 r1 0xffffffffffff9e0 1152921504606845408 r2 0x1100002d0 4563403472 r3 0x1 1 r4 0xffffffffffffad0 1152921504606845648 r5 0xffffffffffffae0 1152921504606845664 r6 0x800000000000d032 9223372036854829106 what has gone in registers as a result of all this is garbage values. I do not want to handle things in integer as then aliging integer becomes a= mess in 64 bit mode. Now let's take int addr as long addr64[64] of what I = have done in my patch [attached in my previous mail]. I am going to use the= same program but will print byte by byte on what comes in my *addr64. Sinc= e it is long, I print lower 32 bits first and then higher 32 bits via my pa= tch variable val.. The output is as follows after applying my patch:- (gdb) b main Breakpoint 1 at 0x100007dc: file /home/XYZ/gdb_tests.c, line 22. (gdb) r Starting program: /home/XYZ/gdb_tests 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/gdb_tests.c:22 22 printf("Hi Bangalore %x\n",num2print(27, 16, 13, 9.9)); (gdb) call num2print $1 =3D {int (long, float, int, int)} 0x1000006a0 (gdb) call num2print (2, 3, 4, 5) val =3D 0 in regno 3 val =3D 2 in regno 3 val =3D 0 in regno 33 val =3D 2 in regno 33 val =3D 1077936128 in regno 4 val =3D 0 in regno 4 val =3D 4 in regno 5 val =3D 0 in regno 5 val =3D 5 in regno 6 val =3D 0 in regno 6 R2 R3.000000 R4 R5 $2 =3D 2 Check the above output. I have printed my val byte by byte with higher byte= s first and then lower bytes. The first parameter was 2. The *addr64 which is a pointer of long type, is = pointing to 0 which is higher 32 bits and then if we increment addr64 it is= pointing to 2 which lower 32 bits. The second parameter being float used FPR number 33 and GPR 4.. The third parameter being int is aligned correctly by addr64 of long type p= ointer. Lower bits pointing first which is 4 and higher bits pointing at ad= dr64++ address. Technically this is how even the first parameter should hav= e been aligned but it is in reverse. Similarly, to the fourth parameter things align well. So, this is what I am trying to convince that using int addr[64] isn't allo= wing memcpy to copy values into the buffer correctly. We rather use a long = and align this correctly. Let me know what you think. If you feel I can solve this in a better way, l= et me know. I appreciate your patience to read the email and wish to seek y= our guidance on the same. Have a nice day ahead. Thanks and regards, Aditya. --------------------------------------------------------------- PROGRAM #include "stdio.h" int num2print(int num, float num2, int num3, int 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%d\n",num4); return num; } int main(int argc, char** argv) { printf("Hi Bangalore %x\n",num2print(27, 16, 13, 9.9)); return 0; } ---------------------------------------------------------------------- ________________________________ From: Ulrich Weigand Sent: 14 November 2022 21:24 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: >>- 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 succes= sful. Did you actually verify any of this information? I.e. by debugging GDB itself, or by adding debug print statements to store_register? I'm asking because if the above is all true, then your patch to store_register is a complete no-op for this case: Before your patch, you have: int addr[PPC_MAX_REGISTER_SIZE]; [...] memcpy (addr, &buf, 8); [...] regcache->raw_supply (regno, (char *) addr); After your patch, you have: long long addr64[PPC_MAX_REGISTER_SIZE]; [...] memcpy (addr64, &buf, 8); [...] regcache->raw_supply (regno, (char *) addr64); which is exactly the same! Note that both the place that stores into addr[64] and the place that uses it cast to (char *), so whether you declare the array as int or long long does not make any difference whatsoever. Therefore, I believe that something else must be going on that is actually causing the problem you're seeing. You really need to debug the actual behavior in store_register to understand what is in fact going on here. Bye, Ulrich --_000_BY5PR15MB3540177BE8045318983CE968D6059BY5PR15MB3540namp_--