From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 545 invoked by alias); 21 Nov 2003 18:04:29 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 537 invoked from network); 21 Nov 2003 18:04:28 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 21 Nov 2003 18:04:28 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id BB46E2B8F; Fri, 21 Nov 2003 13:04:25 -0500 (EST) Message-ID: <3FBE53A9.10407@redhat.com> Date: Fri, 21 Nov 2003 18:04:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard.Earnshaw@arm.com Cc: Phil Edwards , Richard Earnshaw , gdb@sources.redhat.com Subject: Re: Your change breaks GDB for ARM References: <200311211649.hALGnRt02516@pc960.cambridge.arm.com> Content-Type: multipart/mixed; boundary="------------080106090401080108050405" X-SW-Source: 2003-11/txt/msg00204.txt.bz2 This is a multi-part message in MIME format. --------------080106090401080108050405 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1512 >> oops, missed them. I guess I could #ifdef them out (richard?). Those >> assignments haven't done anything useful since 2002-02-08 when the arm >> became multi-arch partial. > > > Erm, maybe. When you open a remote target via RDP you get the option to > ask the target to set the endianness (or you can ask "tell me your > endianness"). If you select an endianness and it isn't supported, you > should get back the error RDIError_WrongByteSex; if you ask it to tell > you, it will report back either RDIError_BigEndian or > RDIError_LittleEndian. The idea is to allow the board to tell you what it > can support. > > What should be done will depend on when we open the connection to the > board. If it's after we've selected an image to send, then we should pass > the endianness of the image in the initial connection. If it's before, > then we should ask the board. I think the best solution is to delay > connecting to the target until we have an image if possible. That avoids > the situation where we have a target that is bi-endian (eg a simulator -- > most boards are fixed-endian) and it reports the one we don't want -- > there's no way for the remote end to say "I'm currently foo, but I can > also to bar". Try the attached. It warns the user of the conflict and points them at "set endian" for how to change it. The other alternative is to force the endianess based on what the target indicates, but as you note, that could lead to interesting conflicts. Andrew --------------080106090401080108050405 Content-Type: text/plain; name="diffs" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diffs" Content-length: 1153 2003-11-21 Andrew Cagney * remote-rdp.c (rdp_init): Warn the user when there is a conflict between GDB's and the target's byte-order. Index: remote-rdp.c =================================================================== RCS file: /cvs/src/src/gdb/remote-rdp.c,v retrieving revision 1.34 diff -u -r1.34 remote-rdp.c --- remote-rdp.c 11 Jun 2003 13:16:28 -0000 1.34 +++ remote-rdp.c 21 Nov 2003 18:00:53 -0000 @@ -352,11 +352,17 @@ case SERIAL_TIMEOUT: break; case RDP_RES_VALUE_LITTLE_ENDIAN: - target_byte_order = BFD_ENDIAN_LITTLE; + if (TARGET_BYTE_ORDER != BFD_ENDIAN_LITTLE) + warning ("\ +little-endian remote target conflicts with GDB's current (big-endian) byte order,\n\ +see \"set endian\" for how to set the byte order"); sync = 1; break; case RDP_RES_VALUE_BIG_ENDIAN: - target_byte_order = BFD_ENDIAN_BIG; + if (TARGET_BYTE_ORDER != BFD_ENDIAN_BIG) + warning ("\ +big-endian remote target conflicts with GDB's current (little-endian) byte order,\n\ +see \"set endian\" how to set the byte order"); sync = 1; break; default: --------------080106090401080108050405--