From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19242 invoked by alias); 24 Sep 2008 13:37:12 -0000 Received: (qmail 19232 invoked by uid 22791); 24 Sep 2008 13:37:11 -0000 X-Spam-Check-By: sourceware.org Received: from SAGW-PRIMARY.ARC.COM (HELO sadt-richards.arc.com) (62.189.186.51) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 24 Sep 2008 13:36:37 +0000 Received: from sadt-richards.arc.com (localhost.localdomain [127.0.0.1]) by sadt-richards.arc.com (8.13.8/8.13.8) with ESMTP id m8ODaYGL005628 for ; Wed, 24 Sep 2008 14:36:34 +0100 Received: (from richards@localhost) by sadt-richards.arc.com (8.13.8/8.13.8/Submit) id m8ODaY1o005627 for gdb@sourceware.org; Wed, 24 Sep 2008 14:36:34 +0100 Subject: Re: gdb 6.8 selected_byte_order function From: Richard Stuckey To: gdb@sourceware.org In-Reply-To: <1222253904.3506.12.camel@sad-richards.arc.com> References: <1222253904.3506.12.camel@sad-richards.arc.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 24 Sep 2008 13:37:00 -0000 Message-Id: <1222263394.3506.27.camel@sad-richards.arc.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-8.el5_2.2) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-09/txt/msg00132.txt.bz2 Ah, I see. So this function is actually returning the byte order, if any, selected by the user (hence its name!). I think that the question I should have asked is why, in function gdbsim_open in file remote-sim.c, the switch statement has been changed to call selected_byte_order instead of using TARGET_BYTE_ORDER (which is #defined to be gdbarch_byte_order (current_gdbarch)) as it did in the 6.6 code? I suppose this change was because in the 6.6 code there was the comment /* Specify the byte order for the target when it is both selectable and explicitly specified by the user (not auto detected). */ and the code was not actually doing this: calling gdbarch_byte_order was using auto-detection in the case that the user had not specified the byte order. This change caused a difference in the behaviour of the ARC debugger when using the built-in simulator: the 6.6. version used a default of little-endian, whereas in the 6.8 version it is now necessary to issue a "set endian little" command before the "target sim" command, otherwise a "Target byte order unspecified" error is given. Alternatively, using the "file " command before the "target sim" command, instead of after it, has the desired effect. Thanks for clearing this up for me. Richard Stuckey, ARC