From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28215 invoked by alias); 21 Nov 2003 16:49:38 -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 28207 invoked from network); 21 Nov 2003 16:49:36 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sources.redhat.com with SMTP; 21 Nov 2003 16:49:36 -0000 Received: from pc960.cambridge.arm.com (pc960.cambridge.arm.com [10.1.205.4]) by cam-admin0.cambridge.arm.com (8.12.10/8.12.10) with ESMTP id hALGnRbo009731; Fri, 21 Nov 2003 16:49:27 GMT Received: from pc960.cambridge.arm.com (rearnsha@localhost) by pc960.cambridge.arm.com (8.11.6/8.9.3) with ESMTP id hALGnRt02516; Fri, 21 Nov 2003 16:49:27 GMT Message-Id: <200311211649.hALGnRt02516@pc960.cambridge.arm.com> X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha owned process doing -bs To: Andrew Cagney cc: Phil Edwards , Richard Earnshaw , gdb@sources.redhat.com Reply-To: Richard.Earnshaw@arm.com Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. X-Url: http://www.arm.com/ Subject: Re: Your change breaks GDB for ARM In-reply-to: Your message of "Fri, 21 Nov 2003 11:30:58 EST." <3FBE3DC2.8030007@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Nov 2003 16:49:00 -0000 From: Richard Earnshaw X-SW-Source: 2003-11/txt/msg00201.txt.bz2 > A not so trivial find/grep shows: > > cagney@nettle$ frep target_byte_order > arch-utils.c:376:/* ``target_byte_order'' is only used when non- multi-arch. > arch-utils.c:383:static int target_byte_order = BFD_ENDIAN_BIG; > arch-utils.c:384:static int target_byte_order_auto = 1; > arch-utils.c:389: if (target_byte_order_auto) > arch-utils.c:392: return target_byte_order; > arch-utils.c:412: if (target_byte_order_auto) > arch-utils.c:425: target_byte_order_auto = 1; > arch-utils.c:430: target_byte_order_auto = 0; > arch-utils.c:439: target_byte_order_auto = 0; > arch-utils.c:730: && !target_byte_order_auto > > which are all perfectly fine. As for: > > remote-rdp.c:355: target_byte_order = BFD_ENDIAN_LITTLE; > remote-rdp.c:359: target_byte_order = BFD_ENDIAN_BIG; > > 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". R.