From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7003 invoked by alias); 16 Sep 2003 16:38:59 -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 6944 invoked from network); 16 Sep 2003 16:38:56 -0000 Received: from unknown (HELO cordelia.devereux.me.uk) (217.169.15.178) by sources.redhat.com with SMTP; 16 Sep 2003 16:38:56 -0000 Received: from cordelia ([217.169.15.178] helo=cordelia.devereux.me.uk) by cordelia.devereux.me.uk with esmtp (Exim 3.36 #1 (Debian)) id 19zIqt-0005U4-00 for ; Tue, 16 Sep 2003 17:38:55 +0100 To: gdb@sources.redhat.com Subject: gdb -> OcdLibRemote -> Raven | Wiggler -> LittleEndian Arm From: John Devereux Date: Tue, 16 Sep 2003 16:38:00 -0000 Message-ID: <87smmwzo0w.fsf@cordelia.devereux.me.uk> User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-09/txt/msg00200.txt.bz2 Hi, Firstly, apologies if this is off-topic for the list. GDB loads the application into the chip with the wrong endianness! So the instruction opcodes are all scrambled up and the program is garbage. I have tried all four combinations of "set endian" and the "monitor" equivalent, they seem to make no difference. (You can make the program APPEAR correct like this, but it is still wrongly loaded into the chip and does not run). I am using a "raven" type JTAG device with the Sharp LH79520 (a "little-endian" ARM variant). I can load and run programs fine using the Macraigor OCD Commander application. Once loaded like this, I can even use GDB to step through the application. It is just the loading phase which is going wrong. Can anyone shed some light on this? Is anyone doing this with a "little-endian" ARM? I have currently using V5.3 of arm-elf-gdb, tried on both linux and windows. Some more information: GDB uses OCDlibremote to talk to the hardware. The loading process is incorrectly inverting the "endianness", for instructions, *but not for data !!!* How is this even possible? I suppose either gdb or OCDlibremote must be doing some "interpretation", somehow. This happens even when the input file is in a raw s-record format. Could somebody please confirm that they have had this configuration working: gdb -> OcdLibremote -> Raven | Wiggler -> LittleEndian ARM Help! Thanks, -- John Devereux