From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27649 invoked by alias); 17 Sep 2003 14:02:02 -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 27625 invoked from network); 17 Sep 2003 14:02:00 -0000 Received: from unknown (HELO mercury.mv.net) (199.125.85.40) by sources.redhat.com with SMTP; 17 Sep 2003 14:02:00 -0000 Received: (qmail 10248 invoked from network); 17 Sep 2003 10:01:56 -0400 Received: from bnh-3-06.mv.com (HELO ppro) (199.125.99.134) by mercury.mv.net with SMTP; 17 Sep 2003 10:01:56 -0400 X-Peer-Info: remote-ip 199.125.99.134 local-ip 199.125.85.40 local-name mercury.mv.net Message-ID: <002601c37d24$413087a0$c9d145cc@lndnnh.adelphia.net> From: "Peter Reilley" To: "John Devereux" , Cc: "Jim MacGregor" References: <87smmwzo0w.fsf@cordelia.devereux.me.uk> Subject: Re: gdb -> OcdLibRemote -> Raven | Wiggler -> LittleEndian Arm Date: Wed, 17 Sep 2003 14:02:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SW-Source: 2003-09/txt/msg00206.txt.bz2 John; I will try to help you here. Are you running under Linux or Cygwin? You are not using the GDB that was supplied with the package, is there any reason for this? Does the example for the Sharp7 work with your board? What does the data look like if you use the "monitor long" command? With this, you can read memory in the target directly which bypasses GDB's handling of endian issues. OcdLibRemote does not do endian translation on memory access depending on the type of data being transferred. OcdLibRemote has no knowledge of the type of information, data or code, that is flowing to or from memory. Only GDB has this knowledge. Pete. ----- Original Message ----- From: "John Devereux" To: Sent: Tuesday, September 16, 2003 12:38 PM Subject: gdb -> OcdLibRemote -> Raven | Wiggler -> LittleEndian Arm > > 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 >