From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7929 invoked by alias); 4 Feb 2008 11:54:06 -0000 Received: (qmail 7916 invoked by uid 22791); 4 Feb 2008 11:54:06 -0000 X-Spam-Check-By: sourceware.org Received: from s200aog11.obsmtp.com (HELO s200aog11.obsmtp.com) (207.126.144.125) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 04 Feb 2008 11:53:34 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob011.postini.com ([207.126.147.11]) with SMTP; Mon, 04 Feb 2008 11:53:24 UTC Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 5960ADAD6; Mon, 4 Feb 2008 11:53:19 +0000 (GMT) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id E2AC64C00D; Mon, 4 Feb 2008 11:53:18 +0000 (GMT) Received: from [164.129.12.194] (bri0669.bri.st.com [164.129.12.194]) by mail1.bri.st.com (MOS 3.7.5a-GA) with ESMTP id CJQ66824 (AUTH stubbsa); Mon, 4 Feb 2008 11:53:17 GMT Message-ID: <47A6FCAD.6020800@st.com> Date: Mon, 04 Feb 2008 11:54:00 -0000 From: Andrew STUBBS User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jim Blandy Cc: GDB Patches Subject: Re: [patch][sh] mac.l insn endian issue References: <47A2F3AF.4090009@st.com> <8f2776cb0802011440h56d3125x4292eb803ad4771b@mail.gmail.com> In-Reply-To: <8f2776cb0802011440h56d3125x4292eb803ad4771b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-02/txt/msg00066.txt.bz2 Jim Blandy wrote: > I don't think long long is guaranteed to be 64 bits long, but this is > certainly better than what's there now. (I gather that STMicro has a > blanket assignment.) So this looks okay to me. Should Antony add > himself to the write-after-approval list? It uses the same types the original implementation did, so I don't think it's any worse. I suspect that much of the simulator implementation would fall apart if the size of char, short, int and long long were not as expected. ST does indeed have all the proper assignments. I do not know what is the proper thing to do with the write-after-approval list. Antony does not have write access, hence why I was posting it on his behalf. This stuff is usually handled by myself and Denis Pilat, both on the list. If this is not a problem then I shall go ahead and check in the patch (minus the internal ST bug number). Andrew