From patchwork Mon Mar 12 15:41:34 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Simon Marchi X-Patchwork-Id: 26294 Received: (qmail 91680 invoked by alias); 12 Mar 2018 15:42:23 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 91671 invoked by uid 89); 12 Mar 2018 15:42:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.6 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: sesbmg23.ericsson.net Received: from sesbmg23.ericsson.net (HELO sesbmg23.ericsson.net) (193.180.251.37) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Mar 2018 15:42:21 +0000 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FE.4E.11615.ADF96AA5; Mon, 12 Mar 2018 16:42:18 +0100 (CET) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSHC017.ericsson.se (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 12 Mar 2018 16:41:47 +0100 Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Mon, 12 Mar 2018 16:41:47 +0100 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26 via Frontend Transport; Mon, 12 Mar 2018 16:41:47 +0100 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=simon.marchi@ericsson.com; Received: from [142.133.49.54] (192.75.88.130) by MW2PR1501MB2009.namprd15.prod.outlook.com (2603:10b6:302:b::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.15; Mon, 12 Mar 2018 15:41:44 +0000 Subject: Re: [PATCH] Make arm_record_test work on big-endian machines To: Yao Qi , Simon Marchi CC: References: <20180312030943.32669-1-simon.marchi@polymtl.ca> <86tvtle5wo.fsf@gmail.com> From: Simon Marchi Message-ID: Date: Mon, 12 Mar 2018 11:41:34 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <86tvtle5wo.fsf@gmail.com> X-ClientProxiedBy: CY4PR04CA0049.namprd04.prod.outlook.com (2603:10b6:910:4f::14) To MW2PR1501MB2009.namprd15.prod.outlook.com (2603:10b6:302:b::33) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5e051e37-b0d0-46b9-6218-08d5882fc28c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:MW2PR1501MB2009; X-Microsoft-Exchange-Diagnostics: 1; MW2PR1501MB2009; 3:j9q7fm5LU2ZX33vtDsAkFmUUBqOExf5ArE34lwRLehJtBvl9+/CkctGJC3GbzoicvauuikQA6EEY4A6VsfWJJFpziwx4yqESbk7OfOxkE/fDIODmlQ/I5BYWc+rNXF/5h7rF96AL+2TAPkEDAe4DIhzLKr29G5hcjmbzvbAammX3PaNMcyIVaVVYS/jyD03C/Xd+VS9S/eVwsu0C1c1KBTi6lWRwdndfcFn3Ba2jDn7WNzrrFGTzQZye5KsYCKI4; 25:1750CL/eqLCNLREpxskvdhXTHFIpjlF7FjMDVC/hp5SIarrQ3KfkuGmyShFxmKnDDeR+1PHjxdkTRo6NJTZGPYw1qRXWrqxm4FegWAzOy9uNsftsDihx5fR1Koijgteoo33z32QDrLHhTI9H8UB8zlfgXoudHuD9TYcqMlOpQiDwWecJZagmTwyJf0maUh+Lke6wTamA28gmntXp/v1vl+08lVKDyfEyAYhafPr5MVB5/GrQstYrU7GBNd+ZWclUPVjdSQl7VvgvDcL/x81K4FAXYdz1y/2jy5Mfko9FJk5Q8fKL7AmmVwogYJWdsM7YegMW6YSOQlKTJqztrIx65A==; 31:rkgxth13ZFbaRO4jGcJTOOhI5WtBHcrD2vYmPdSRz8irtuEmK7JiGUgMv9/QvYMSSs8qKPfgOw/KFQWAj/y5vXsoVfjeXUDarnaYnjWrTRnJkHyJpiBGHyBAyIgQbNVGF0T7RLslz1Jaiz0VuMBDlS0+lLxGbjWq0/ktx5umThveBhQpdYmZsIj6inIxV6gIbS6mXg4W9PdRhZtAEb2AuhoFLV9xKDouWc939tihwFc= X-MS-TrafficTypeDiagnostic: MW2PR1501MB2009: X-Microsoft-Exchange-Diagnostics: 1; MW2PR1501MB2009; 20:XQUOX5aSsaIo6Om8iBvmwCHsCzr0+183fjP+DHXhqDA0F7pZ2GsGrriLmLydABOcwy4a1kzqafXy5O3Mh6y8ie11y7kzWzDEja3cbS45xQSEQrfLUJP4nfcKx5gRqK7l+Nnf5OiPk1yZCeasfuOjvxGEWy7sdrsFi3Htxl4x57YKceAhI/SqJsn+a/99LBZnvmpNSV4UwrrC9K0Zf+3k8WGAV6TzaaixlBpj/WqZxnDkaKPCYl7Z3aZsi+1yMnUvWDRhlgJ92jdU7RlIJ1gP3EZXk4BRAMxLmki6z7ZpG0E5H0bxtoB/NH4/KuykJW77vMia2QCbWFDh3jo3B30A+cSfhHQYPVGSdbZqokGj1MUPjXC8+5YZYY/5yNA2UBeLbB9VtYs9GtYkR9awUK/tLR7qgc7WoA5TmeJJWuJFdTXWopZbmXdRDx13cSGfk1mjyZiIXBJuxXmUvJ901COdVKRlWMhUJUcxf3vzrsFPKgJDdub3nbef5M6RAyruNKob; 4:2fwLz5HZZQLYeTifN3OOkPbfXwXW4VlMD+U8DtvA9X96J2B6XuAx/6d+pdkzEVjTsODKSd8fLQ8I8WlCgk8l0rHd9iiXdLqBKL+50RMYmo2nPcZ3YCIQ7AcocXl9gwsT9Kb7d6JQtf2gVIzvEw7wTqFCDV+g/NFoZKGehFIWQsA8epd6Zvx6SDFFhIAAO2wGf6zKOCJ8LV0wb7YQQfM3UOUj3HoR+wabfuQYCKg5+1WleP2uCmTGbTKxHI+VoL5lOHsDbJEuXbxy7+ijaqUP94mzjgNECHvUslq0JSDKCMm7G0kZs4QP2MEtOxMDDHD7 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231220)(944501244)(52105095)(3002001)(10201501046)(93006095)(93001095)(6041310)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:MW2PR1501MB2009; BCL:0; PCL:0; RULEID:; SRVR:MW2PR1501MB2009; X-Forefront-PRVS: 06098A2863 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(346002)(376002)(39860400002)(396003)(366004)(39380400002)(51914003)(377424004)(189003)(199004)(76104003)(305945005)(8936002)(64126003)(65956001)(39060400002)(230700001)(81166006)(229853002)(66066001)(53546011)(65806001)(106356001)(47776003)(86362001)(81156014)(6116002)(36756003)(478600001)(16576012)(316002)(3846002)(8676002)(50466002)(7736002)(6246003)(52146003)(53936002)(16526019)(23676004)(59450400001)(31696002)(186003)(52116002)(4326008)(2486003)(31686004)(26005)(105586002)(97736004)(65826007)(49976009)(76176011)(6666003)(2950100002)(58126008)(5660300001)(6486002)(2906002)(25786009)(386003)(110136005)(68736007)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:MW2PR1501MB2009; H:[142.133.49.54]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtNVzJQUjE1MDFNQjIwMDk7MjM6dDU5MWRqZ1JIc0FtYXdoc1JFdithczh3?= =?utf-8?B?TlVyWEJOTXp6d2U2ZlFoanpvOHRiQVNMcDNadFp3Y2NCMnc4UnV5QU1kWXEv?= =?utf-8?B?a0IyOVBnd0pCUnNqQzd5S3ZIRlZXcVQyZHpXVkc0OGpTcWdPa1JlSmZsS2dq?= =?utf-8?B?bkxsSitnN3pXcTFSUFFpWkN6MDh4d250NW9qSHlEZVhwMUpOQ3lIdzNNL0lS?= =?utf-8?B?V1hqbFZyM0tLNGwxODNtOHVmbi9makZhY0s2alM2SkNHdWoxTmQ2T2p0U0RY?= =?utf-8?B?SGtJZnMxRHNqWU5Ba2FuYkJ4RXhZMVFFRXhBcW1DNW45bGhVREhOazZBWmc3?= =?utf-8?B?NTBYTVZtcHNwY2FuSzRzMVRWSGNtOUhPZG84ODViK3ByMVJueTVkcmJHUUlB?= =?utf-8?B?VFhHMENQNzZDb3gwMGhSUnpNL3VlNHhFRUtBS1M1M1BpY2g1NzR0NWRMdi92?= =?utf-8?B?djkyTnNUYTNKcTZWTlVXWlhPMjV3ZUVVazI1SEs0TE5DaDNnb2F5Y3RXWExV?= =?utf-8?B?bWhaeDhNR0NoNTg2WXlWM25tZFVMcDZlWnMybS9zazB0cXRheDc2Qkkwck1U?= =?utf-8?B?VVZMNjQ5RnFVc2haR0tBU09MK1ByS1IvY0Z2M29hakU5VW5lQkJja3dXY1da?= =?utf-8?B?cmhSL3duRGI3Ymk2cHNkN3A0amV4L1JQWVhwOWxTUjRKSUVlSjgxaXVhWGJM?= =?utf-8?B?MXZsMnp4MG5ORHBPb2JsUU5rbnBBaFZRa1NxOFFUNjZ4eVNaMFNyTGsvcWhv?= =?utf-8?B?endwRmxURTc2Rkw0cGovWGtBSEFsemZ2QndQYXYxQnF2N01JR2dJNmttWTZp?= =?utf-8?B?M0VMSHpyYno2T2ZuSUVvb2dyaDZBbDBIUEU2WVdta1p2WDVJZ1FSNGtBNUwr?= =?utf-8?B?UktOaWpHbURNRUtCcFpQVzd6RW5tNXFyZ3duZDE5TDZQSGliNHpxa0J3NmF6?= =?utf-8?B?Z3RMSDR2Mm5TQVNvZEFlWmwvS1RmdEFOSFZ0WkFUUkNuWm1GV1g0NUNDYncw?= =?utf-8?B?b1pPeVJKMjlxbDZUNTlPREhtU3lSdzMvWjVocTNtQ0hhWGRRRmZpZDBkemh1?= =?utf-8?B?VjVYa0pubm8wNTBUNnFhMERkdXYvUytLS3dnaGQxd1lTMHZ1eGwrSWFWeHRq?= =?utf-8?B?cVNwSEQvMEsxYjdZK2x0dDNDaEdIalhlOExKUDZjc044RHdMQlBYb2xrSk9p?= =?utf-8?B?TllxVTRtVVVnaHJ2MklmNE1ENDRCQjhDK2VBUWlNRG8xOVJiNDlzZXBVUG5O?= =?utf-8?B?VzVuVDJMSGJqQWZLdDQ3ZFBtcisrNFlEWG1PTkhqak5DTXM0ZTBZbWhrZkVL?= =?utf-8?B?dk0rN1ZITDl1TTNIcDZJU2kraHM5TnMranQ5OE5BNEhZc00rZU9uQzRzNFNt?= =?utf-8?B?bDR3bTRtOTd5TGJ1UHdKckF4MHg5SGcxbUhpYmlCaGV4Qy9qQURIeHlFRXVJ?= =?utf-8?B?MFBETUZWQVRCbWdqR281c21RaThXT04wcm9OLzhOcmpTSFZtMExZUm1YYU1W?= =?utf-8?B?NER4a1dKOVBvSU9Cb2ZtMlN6RzFwcmRBS21tZ2ZadHptUVFYc2hneVNtQktj?= =?utf-8?B?OGdJelRLTDU5Y2xrZGRocjNPcUhRNDBZNnJhWjhMZVZUZkl6TGdOYlZCZmxF?= =?utf-8?B?WUpuMndpS0tzWlFVU0xiak40eFBONlV2L0NkZ2R2UjVDWlBLaHF0bUJScGN5?= =?utf-8?B?RXdBSHlaNzU4bTNNanlXaHhNNSswU1BSOVpFd1JkYVJ4aFFRRWFITWpJVzBX?= =?utf-8?B?a3UzUGwyRlh6U1QydkNaeGsreVp6dGU2bHJUVE9pd0c2ZlFoWGlKTkZ0S2ZZ?= =?utf-8?B?WC85ZEFhVk92RnhSRHlNQndwVk5JcUJoK2RZRkxYOGg0TEo4WENFZFFDaXVj?= =?utf-8?B?WVpKSnFsNHV2UHBnZ1p6SCt0b1Y4aE5hU0NlTFFuU0JjOXpyRmJid2ZtZ0dy?= =?utf-8?B?b0xobUJFcFdndjQ2ekxKVzdoTTA2cklrdzlQSXhjVm1WU0UwMnMzenVtV2ZH?= =?utf-8?B?MVJqR1VMQ1Q1QjlaOUpIMFlVOHA0Y2VWQzU2UEp3PT0=?= X-Microsoft-Antispam-Message-Info: BOu9dzw/ZxvbpgXD0KrT+1viXfUEcZ2qkwvSyd5ziERvsCUNK+axZ10P3IpxlmUWGKw62/1ogvTIZ+J23seqeiZP7XV6hmX/bxUvZCaQIhglvqIV5No+yLZAyPAXoFdlrRG/CG4euieMWg43CpHGVvCuEEf87uVQLPxlZjVov4cEpe3MGkYf+JKAUmwBAxHG X-Microsoft-Exchange-Diagnostics: 1; MW2PR1501MB2009; 6:qhafG1GYinJyMSmX5m39/+FtXCLMnGAE3nOLkHLgF9t5Sc6UsSVaCD0CUilNzHbQiA9ot2ENKBl/PWTNxN74oaUBLrKe7n5n7XAe8739x7JFDAN/2Z3G2HSUXzXD0AV8ybCGNfFJZawWzIB6UoJulZlXFljd37ZqN+NvvR+U+y9JCR5XLvJWCave7m5WdTw6SDDvylDr/hyTEV9cOBvM5on/GOqG/JZwZoCMMvvdXJ+tHF/lhhYBzYSU0tYKwRidyFDoELG49Fqe4b1pGLA+GkctQmxihdpW0yfI9bflafY5E5lSJD/CkrRkD6I2ZBhwDIqt138kY+a2flo/ef8+ld9Q3qaLzGuSBwT1+2yxzUA=; 5:q/E7lEE46nsl4HvYcnnliUOOwwuhv7RCerKwqoOcDE+32tOZvyx6Wi7f1Wal7HmSTNWGLQzAvJLe40EoF8YxnxJ5lHsI26cM4NKlMpA5jz8Up2L3WQAWGkL1aU10zoFoLHRljt+5iW5vuSXGUeYwE+skXvkYyIiS/BKH69u6Hrg=; 24:coQ+R0DoCBueOvq4H5CGin2q0/oWmzXlY4eaEHBxAfw//xRfhf5IeK2XGco3D59/ftbWhOiaJyrUsvPlRm0ZoRsfxViG3V0GTHJWISh6R6k=; 7:h2DUk3Jf4bJReR0vjA7AWVagHS6s3R7Uhq3sSASzVLPFIq/rVt1lg5kogZBDY2mkKacmOHwOp/W3FMNoUmzuOU/r5E2rS7dJQqJIkc1Zo9M4yc2ZKCS8nJnrCA46ZF1a4F8SqTJER3AKWJwro2WJ7ZMRJzVFEOCfibaM/OlFtkcOyEaBejQNGXN/fHKOmUIBRi4x4Y0JAOIG4lOzZwKea/99QaOPoheN2gLtiKmn7uNcF54Xv/YDw+nfXRuPe4K1 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2018 15:41:44.7863 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5e051e37-b0d0-46b9-6218-08d5882fc28c X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR1501MB2009 X-OriginatorOrg: ericsson.com X-IsSubscribed: yes On 2018-03-12 10:15, Yao Qi wrote: > Simon Marchi writes: > >> While running selftests on a big-endian PPC, I noticed arm_record_test >> failed a test. The reason is that the gdbarch_find_by_info call is done >> with BFD_ENDIAN_UNKNOWN byte order in the info structure. In that case, >> it uses the byte order of the current default BFD, which happened to be >> big-endian on that GDB build, and the gdbarch returned is a big-endian >> one. The instruction used for the 32-bits part of the test is written >> in little-endian form, so GDB fails to decode the instruction >> properly. > > The test instructions are endianess-neutral, because they are written as > uint16_t, and that is why you didn't have to adjust 16-bit thumb > instructions in the tests. Ok, and I think there was something confusing me with the order of the Thumb2 instructions (maybe it's the order the bytes are written in the comment). From what I understand now after playing with objdump, the two 16-bit parts of a Thumb2 instructions are not swapped on little endian, they are considered as two separate instructions (I guess it makes sense, otherwise it would be impossible to determine whether the next instruction is 16-bit or 32-bit long). So only the two bytes of each 16-bit chunk are swapped when switching between big and little endian. In memory, the bytes for that instruction should look like this: little endian: 0x1d, 0xee, 0x70, 0x7f big endian: 0xee, 0x1d, 0x7f, 0x70 And in both cases, we want the value in arm_record->arm_insn to end up containing 0xee1d7f70. Is that right? >> >> Since ARM supports both endiannesses, and it should be possible to debug >> using an host of both endiannesses, I changed the test to check with >> gdbarches of both endiannesses. > > Although ARM supports both endianesses, the big endian has two variants, > BE-32 and BE-8. Before ARMv6, it was BE-32. In ARMv6, BE-8 must be > supported, but support of BE-32 is implementation defined. ARMv7 drops > the BE-32 support. With BE-8, data is big endian and code is little > endian. Thumb-2 instruction was introduced in armv6t2, so it is still > likely to have both big endian and little endian thumb-2 instructions > code. Ok, thanks for the info. > As I said, the test case is written in an endianess-neutral way, > > static const uint16_t insns[] = { > /* 1d ee 70 7f mrc 15, 0, r7, cr13, cr0, {3} */ > 0xee1d, 0x7f70, > }; If my assumption above is right, everything looks right until extract_arm_insn. The 4-byte instruction is extracted with insn_record->arm_insn = (uint32_t) extract_unsigned_integer (&buf[0], insn_size, gdbarch_byte_order_for_code (insn_record->gdbarch)); Since the instruction is extracted as a single 4-byte value, on little endian, extract_arm_insn leaves insn_record->arm_insn equal to 0x7f70ee1d. On big endian, it leaves it equal to 0xee1d7f70. Hence the need for the word swapping you show below. In my opinion, it should be extract_arm_insn's responsibility to leave insn_record->arm_insn with a consistent value regardless of the target/host endiannesses. The easiest way would be to read the instruction as two 16-bit integers instead of one 32-bit one. Or we can still do the word swap shown below (only if the code is little endian), but at least I think it would make more sense to do it in extract_arm_insn. > > but the arm process recording processes thumb-2 instruction as one > 32-bit instruction, so that it has this, > > /* Swap first half of 32bit thumb instruction with second half. */ > arm_record->arm_insn > = (arm_record->arm_insn >> 16) | (arm_record->arm_insn << 16); > I wonder this is the cause of the test fail, that is, we don't need to > swap them in big endian. Since I've never run GDB tests on arm big > endian target, I am not very confident on my fix below. It fixes the > test fail on ppc64, and also the fail with your patch to change the test > with two different endianess. What do you think about the patch below? Functionally, it should be identical to what you suggested, but I think it's clear to fix extract_arm_insn instead. From 925b2f54e53f39b8713dccc7788b3f10fccc374c Mon Sep 17 00:00:00 2001 From: Simon Marchi Date: Mon, 12 Mar 2018 11:28:29 -0400 Subject: [PATCH] extract_arm_insn: Read 32-bit instruction as two 16-bit words --- gdb/arm-tdep.c | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c index ef7e66b..e92ac13 100644 --- a/gdb/arm-tdep.c +++ b/gdb/arm-tdep.c @@ -13089,14 +13089,25 @@ extract_arm_insn (abstract_memory_reader& reader, insn_decode_record *insn_record, uint32_t insn_size) { gdb_byte buf[insn_size]; - memset (&buf[0], 0, insn_size); + gdb_assert (insn_size == 2 || insn_size == 4); + if (!reader.read (insn_record->this_addr, buf, insn_size)) return 1; - insn_record->arm_insn = (uint32_t) extract_unsigned_integer (&buf[0], - insn_size, - gdbarch_byte_order_for_code (insn_record->gdbarch)); + + bfd_endian endian = gdbarch_byte_order_for_code (insn_record->gdbarch); + + insn_record->arm_insn + = (uint32_t) extract_unsigned_integer (&buf[0], 2, endian); + + if (insn_size == 4) + { + insn_record->arm_insn <<= 16; + insn_record->arm_insn + |= (uint32_t) extract_unsigned_integer (&buf[2], 2, endian); + } + return 0; } @@ -13188,10 +13199,6 @@ decode_insn (abstract_memory_reader &reader, insn_decode_record *arm_record, /* As thumb does not have condition codes, we set negative. */ arm_record->cond = -1; - /* Swap first half of 32bit thumb instruction with second half. */ - arm_record->arm_insn - = (arm_record->arm_insn >> 16) | (arm_record->arm_insn << 16); - ret = thumb2_record_decode_insn_handler (arm_record); if (ret != ARM_RECORD_SUCCESS)