From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8271 invoked by alias); 1 Mar 2019 22:15:55 -0000 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 Received: (qmail 8110 invoked by uid 89); 1 Mar 2019 22:15:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:0800 X-HELO: quarantine.blueorigin.com Received: from mx30.blueorigin.com (HELO quarantine.blueorigin.com) (50.225.231.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 01 Mar 2019 22:15:48 +0000 Received: from pps.filterd (quarantine.blueorigin.com [127.0.0.1]) by quarantine.blueorigin.com (8.16.0.27/8.16.0.27) with SMTP id x21MCork012652; Fri, 1 Mar 2019 14:15:40 -0800 Received: from mail02.blueorigin.com (MAIL02.blueorigin.com [10.1.1.46]) by quarantine.blueorigin.com with ESMTP id 2qyb59r4ce-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 01 Mar 2019 14:15:40 -0800 Received: from MAIL01.blueorigin.com (10.1.1.45) by MAIL02.blueorigin.com (10.1.1.46) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 1 Mar 2019 14:15:38 -0800 Received: from MAIL01.blueorigin.com ([fe80::38ac:bda:468a:aa3f]) by MAIL01.blueorigin.com ([fe80::38ac:bda:468a:aa3f%21]) with mapi id 15.00.1395.000; Fri, 1 Mar 2019 14:15:38 -0800 From: Jeff Wandling To: Simon Marchi CC: "gdb@sourceware.org" Subject: RE: [EXTERNAL] Re: Debugging big-endian ARM target from little-endian host Date: Fri, 01 Mar 2019 22:15:00 -0000 Message-ID: <0d0fafabebda4de28cd415f0a9b5d7ce@MAIL01.blueorigin.com> References: <0338ed2b221c8a9e40d41037a66d847e@polymtl.ca> <672b1bfc87164c27a6a3e655eec6d813@MAIL01.blueorigin.com> <1222341d5bd82992b2cc14a451d5904a@polymtl.ca> In-Reply-To: <1222341d5bd82992b2cc14a451d5904a@polymtl.ca> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2019-03/txt/msg00005.txt.bz2 Yes, I am using -endian big with JLinkGDBServer -----Original Message----- From: Simon Marchi =20 Sent: Friday, March 1, 2019 1:54 PM To: Jeff Wandling Cc: gdb@sourceware.org Subject: [EXTERNAL] Re: Debugging big-endian ARM target from little-endian = host On 2019-03-01 14:45, Jeff Wandling wrote: > -----Original Message----- > From: Simon Marchi > Sent: Thursday, February 28, 2019 6:02 AM > To: Jeff Wandling > Cc: gdb@sourceware.org > Subject: Re: Debugging big-endian ARM target from little-endian host >=20 > > Do "set debug remote 1" and then "continue" so that you hit your=20 > breakpoint. Towards the end of the debug output, you should see a=20 > vCont;c packet, with a "stop reply" packet (assuming JLink supports=20 > the vCont packet, and you use the all-stop mode). Here's an example=20 > with > x86-64: >=20 > Sending packet: $vCont;c:p209a.-1#da...Packet received: > T05swbreak:;06:10ddffffff7f0000;07:10ddffffff7f0000;10:0c4655555555000 > 0;thread:p209a.209a;core:0; >=20 > In the response, you can see a few pairs of register number/register=20 > values. Since you know the PC you expect your program to stop at, it=20 > should be fairly easy to spot the PC register. The value should be in=20 > big endian, in your case. In my case, 10:0c46555555550000 corresponds=20 > to the PC value in little endian: >=20 > (gdb) p $pc > $1 =3D (void (*)()) 0x55555555460c >=20 > If you have trouble interpreting the debug remote output, pastebin it=20 > and send the link. > >=20 > Results: >=20 > https://gist.github.com/jwandblue/e1ede3f41a4e7effa7e80d5066c96724 >=20 > The interesting result was the JLinkGDBServer doesn't emit the "vCont" > packet unless I am misreading the result. >=20 > I'm boxed into a corner since I have a SEGGER JLink dongol and so=20 > choosing to use JLinkGDBServer is not arbitrary. Ok, so it just seems that this "gdbserver" implementation doesn't support v= Cont, so GDB uses the older 'c' packet. It should not change anything for = your endianness problem. The registers are read using the 'g' packet, just after the 'c'. I don't k= now the exact register layout for your architecture, but let's just split t= he result in groups of 4 bytes: 40000000 48ffffff 00000000 01000000 00000000 00000000 00000000 3f010008 314d8952 c1444c00 516c228d 16acb100 917c4ca8 00010180 08000000 b0120000 <--- Probably PC 9b030000 db030000 db030000 ... So it looks like jlinkgdbserver sends you the registers in the wrong endian= ness, if I understand correctly. Googling around, there seems to be an -en= dian flag to pass to jlinkgdbserver. Are you using it? Simon