From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id 2FDBE3858D28 for ; Wed, 11 Oct 2023 16:49:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2FDBE3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-1c7373cff01so9449825ad.1 for ; Wed, 11 Oct 2023 09:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697042957; x=1697647757; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=mK6ZuDJX6K8zDQR7K7vR/TQyKtvjQNM/Ga/iO/iBX+c=; b=G+iNcMZNl3cH9LMLm09zSMffR0ZExr+0+vuD82+tE02NbB9S3a4x5n+omMhLv3Msbd 3t2wxCFqomWTXIaoSSmA9G23J+mL2LRgyngXJ/zoso/3BcXUv2WR9vTiywYqAlokWMXA mWm7vXTZTZTugoaVRGFUvGhUKLhIeUrSWqhh4h4TeG2NNPREiOEiV/Ny3QKdoWjQOeCn diMp5jCJx4D7Z5AEgUWrJvLJn0Qa/R7NgfuAb0vC2aUF7sOn+aRWtsjhtdia8z/HtFSk EGNWLE5qxn84i5T3SgdiIxAFccO3ipRyWIf4nk1zSCBHVJDjDAtQTKUNA2ROHkIxq2Ag 0l9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697042957; x=1697647757; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mK6ZuDJX6K8zDQR7K7vR/TQyKtvjQNM/Ga/iO/iBX+c=; b=AXX6QKRsrDKK2nCbG+pQseFY0R7Em9/vUipZdq4bXV04m1mOMfIGYJkaHDhwsGy+wh yLXl3HWOpvxFVoufmxAOlOarH0G/mnEBsupgiz6ffpGpSZRK2n3frDPSl5V/0xn6Fv4v KruGb0S7ufBvQFRZ46H7566CyF7ldoqqBjaoroZQk20NqVXxuqu3QH7fYU7S87O3RNkC 8WkN6CFetI3eCaGTX/jMA4rSN/U2ZGd13/CQxbj9BcE8JnjUcazqykLVm/RGJe1y9YOp RG3kfm6FG1xbQ9dryTRhFAIPRZD5X6cT4JJh4aPwl8c9M2NjP/NXxgDwmTBiJtc/5dOm tVSw== X-Gm-Message-State: AOJu0YyTktyj4qK5oJcoTNvHO1Sm0XOXamQ4scKUgodxHOMFSThwP72X nxDfezhMMNS1pB0smX3UscNrOLszg8A= X-Google-Smtp-Source: AGHT+IE3YV3BNjdQHe/Esa26aAmXPHDvwGoAP2fvgzmi51wvYYKnSUNLENsQBAwYQqmMLdsAtrd1jg== X-Received: by 2002:a17:903:493:b0:1c0:bcbc:d66 with SMTP id jj19-20020a170903049300b001c0bcbc0d66mr23970740plb.7.1697042957040; Wed, 11 Oct 2023 09:49:17 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id ij25-20020a170902ab5900b001c755810f89sm49874plb.181.2023.10.11.09.49.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Oct 2023 09:49:16 -0700 (PDT) Message-ID: <5894d55f-d930-43c7-8811-d1e9bcda688b@gmail.com> Date: Wed, 11 Oct 2023 10:49:11 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Fwd: [RFA] Fix for mcore simulator Content-Language: en-US To: Martin Simmons Cc: gdb@sourceware.org References: <1d854df9-b28c-41eb-af7c-e3a423885558@gmail.com> <9f2c4844-c2ef-417b-ba09-9f71c7066759@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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: On 10/10/23 15:35, Martin Simmons wrote: >>>>>> On Thu, 5 Oct 2023 10:09:44 -0600, Jeff Law via Gdb said: >> >> Of course if the code is supposed to behave the same, then that points >> to problems elsewhere (assembler, linker, simulator). Sure enough the >> mcore simulator was mis-handling the sign extension instructions. The >> simulator implementation of sextb is via paired shift-by-24 operations. >> Similarly the simulator implements sexth via paired shift-by-16 operations. >> >> The temporary holding the value was declared as a "long" thus this >> approach worked fine for hosts with a 32 bit wide long and failed >> miserably for hosts with a 64 bit wide long. >> >> This patch makes the shift count automatically adjust based on the size >> of the temporary. It includes a simple test for sextb and sexth. I >> have _not_ done a full audit of the mcore simulator for more 32->64 bit >> issues. > > The use of long seems bogus to me. Why not just declare tmp as int32_t? That code likely predates any modernization efforts in gdbsim and binutils-gdb as a whole -- it's the old interp style simulator that was common in the 90s. I wouldn't lose any sleep if someone took up that task (modernizing that codebase) but my interest in mcore is essentially zero, so it won't be me. Jeff