From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48823 invoked by alias); 28 Feb 2019 14:02:00 -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 48713 invoked by uid 89); 28 Feb 2019 14:01:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=$pc X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Feb 2019 14:01:52 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id x1SE1jdg018565 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 28 Feb 2019 09:01:50 -0500 Received: by simark.ca (Postfix, from userid 112) id D094D1E658; Thu, 28 Feb 2019 09:01:45 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 1BF661E16B; Thu, 28 Feb 2019 09:01:44 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 28 Feb 2019 14:02:00 -0000 From: Simon Marchi To: Jeff Wandling Cc: gdb@sourceware.org Subject: Re: Debugging big-endian ARM target from little-endian host In-Reply-To: <42ffc1dbeae74ebfb7b29787a0ad4c32@MAIL01.blueorigin.com> References: <42ffc1dbeae74ebfb7b29787a0ad4c32@MAIL01.blueorigin.com> Message-ID: <0338ed2b221c8a9e40d41037a66d847e@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00084.txt.bz2 On 2019-02-27 14:50, Jeff Wandling wrote: > I have a question about the method to configure gdb(1) to debug > big-endian target firmware. > > Question and comments, ping me directly. I'll summarize as warranted > based on responses. Thanks in advance. Hi Jeff, You seem to have identified multiple issues, so let's focus on the big-endian one first, which seems the most problematic. > The symptom/problem: > > When the target firmware is compiled for big-endian, and when > JLinkGDBServer is running such that the target is big-endian, then > when debugging with gdb the capability to break and step fails. > > The question(s) are: > > If the remote target is big-endian, and the host is little-endian, is > there something _more_ needed to be done in gdb(1) configuration to > conduct a debug session whereas the endianness of the data and > registers is interpreted as expected? > Is there a setting in gdb that enforces a behavior to step INTO > assembly functions rather than OVER them even when "si" is used? > > Setup: > Target device TMS570LC4357 (Hercules, TMS 570) ARM Cortex-R5 > Target firmware, C/ASM code compiled as "big endian" (-mbig-endian, > -EB, etc..) > > All compilations made with: > $ arm-none-eabi-gcc --version > arm-none-eabi-gcc (15:4.9.3+svn231177-1) 4.9.3 20150529 (prerelease) > > $ arm-none-eabi-as --version > GNU assembler (2.26-4ubuntu1+8) 2.26 > > $ arm-none-eabi-ar --version > GNU ar (2.26-4ubuntu1+8) 2.26 > > $ arm-none-eabi-ld --version > GNU ld (2.26-4ubuntu1+8) 2.26 > > > Host: > Little-endian Xeon with Ubuntu > Host runs JLinkGDBServer.exe ( version V642-f) > > Host runs gdb(1) version 8.2 > > GDB was configured as follows: > configure --host=x86_64-linux-gnu --target=arm-none-eabi > --with-auto-load-dir=:/auto-load > --with-auto-load-safe-path=:/auto-load > --with-expat > --with-gdb-datadir=/usr/lib/arm-none-eabi/share/gdb > --with-jit-reader-dir=/usr/lib/lib/gdb > --without-libunwind-ia64 > --without-lzma > --without-babeltrace > --without-intel-pt > --disable-libmcheck > --without-mpfr > --without-guile > --with-separate-debug-dir=/usr/lib/lib/debug > --with-system-gdbinit=/usr/lib/arm-none-eabi/lib/gdbinit > > > Data and explanation: > > Suppose the firmware has a function at physical address 0x0000003C > (somewhere in the first block of flash) > Suppose the breakpoint set in gdb is at this address. > > If the breakpoint is set, and then the firmware is run, the gdb traps > on the breakpoint: > > GNU gdb (GDB) 8.2 > Copyright (C) 2018 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "--host=x86_64-linux-gnu > --target=arm-none-eabi". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > . > Find the GDB manual and other documentation resources online at: > . > > For help, type "help". > Type "apropos word" to search for commands related to "word". > Reading symbols from image.elf...done. > Remote debugging using localhost:2331 > 0x00000000 in ?? () > The target endianness is set automatically (currently big endian) > (gdb) load > Loading section .text, size 0x4758 lma 0x20 > Loading section .rodata, size 0x200 lma 0x4778 > Start address 0x3c, load size 18776 > Transfer rate: 6111 KB/sec, 6258 bytes/write. > (gdb) br _c_int00 > Breakpoint 1 at 0x3c: file source/HL_sys_startup.c, line 88. > (gdb) c > Continuing. > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x3c000000 in ?? () > (gdb) list > 1 > 2 > 3 int main() > 4 { > 5 return 0; > 6 } > (gdb) step > Cannot find bounds of current function > > Attempts to step fail > "Cannot find bounds of current function" > I presume this is because the big-endian interpretation of the PC is > an address where the function is not located.. The function is at > physical address 0x3C. > (gdb) monitor regs > PC = 3C000000, CPSR = 000003D3 (SVC mode, ARM FIQ dis. IRQ dis.) > R0 = 00173180, R1 = FFFFFF48, R2 = 00000000, R3 = D3D3E1AB > R4 = 00000000, R5 = 08000B60, R6 = 00000000, R7 = 0800013F > USR: R8 =52894D31, R9 =084C44C1, R10=8D206C51, R11 =58311700, R12 > =AC0C7CD7 > R13=08000BA0, R14=08000137 > FIQ: R8 =180A8884, R9 =00200200, R10=97D50C37, R11 =081E1C10, R12 > =18A40002 > R13=00008000, R14=9167F273, SPSR=2E0008E8 > SVC: R13=04A9A810, R14=00000040, SPSR=2E0018E8 > ABT: R13=2E6FA985, R14=3C000004, SPSR=00000393 > IRQ: R13=2067F940, R14=0D044C2C, SPSR=2E0018E9 > UND: R13=01004080, R14=00000008, SPSR=0000039B Yeah, it seems like all registers are interpreted with the wrong endianness. First, a sanity check, the command "show endian" should show that GDB knows the target is big endian. In the remote protocol (which GDB uses to communicate with your target), register values need to be transmitted in target order (big endian in your case). Let's verify that it's what JLink sends. Do "set debug remote 1" and then "continue" so that you hit your breakpoint. Towards the end of the debug output, you should see a vCont;c packet, with a "stop reply" packet (assuming JLink supports the vCont packet, and you use the all-stop mode). Here's an example with x86-64: Sending packet: $vCont;c:p209a.-1#da...Packet received: T05swbreak:;06:10ddffffff7f0000;07:10ddffffff7f0000;10:0c46555555550000;thread:p209a.209a;core:0; In the response, you can see a few pairs of register number/register values. Since you know the PC you expect your program to stop at, it should be fairly easy to spot the PC register. The value should be in big endian, in your case. In my case, 10:0c46555555550000 corresponds to the PC value in little endian: (gdb) p $pc $1 = (void (*)()) 0x55555555460c If you have trouble interpreting the debug remote output, pastebin it and send the link. Based on what you find here, we should know whether GDB or JLink's gdbserver is at fault. Simon