From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25282 invoked by alias); 24 Sep 2008 13:49:46 -0000 Received: (qmail 25272 invoked by uid 22791); 24 Sep 2008 13:49:45 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 24 Sep 2008 13:49:06 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id ADF9A10CF1; Wed, 24 Sep 2008 13:49:04 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 899AF101A1; Wed, 24 Sep 2008 13:49:04 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KiUjo-0005jo-2M; Wed, 24 Sep 2008 09:49:04 -0400 Date: Wed, 24 Sep 2008 13:49:00 -0000 From: Daniel Jacobowitz To: Richard Stuckey Cc: gdb@sourceware.org Subject: Re: gdb 6.8 selected_byte_order function Message-ID: <20080924134904.GA21715@caradoc.them.org> Mail-Followup-To: Richard Stuckey , gdb@sourceware.org References: <1222253904.3506.12.camel@sad-richards.arc.com> <1222263394.3506.27.camel@sad-richards.arc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1222263394.3506.27.camel@sad-richards.arc.com> User-Agent: Mutt/1.5.17 (2008-05-11) 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/msg00133.txt.bz2 On Wed, Sep 24, 2008 at 02:36:34PM +0100, Richard Stuckey wrote: > 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 think you can find a discussion of this on the list archives at around the time it was made. > 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. That's exactly right. I believe the problem was that some simulators do not support -E little and -E big. They were probably for targets where switching endianness did not make sense; no need to specify it, then. > 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. If it's the default you're concerned with, try searching for WITH_DEFAULT_TARGET_BYTE_ORDER ? -- Daniel Jacobowitz CodeSourcery