From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83836 invoked by alias); 27 Feb 2019 19:50:21 -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 83798 invoked by uid 89); 27 Feb 2019 19:50:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=conduct, dis, symptom, mbigendian X-HELO: quarantine.blueorigin.com Received: from firewall.blueorigin.com (HELO quarantine.blueorigin.com) (72.165.233.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 27 Feb 2019 19:50:11 +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 x1RJfZ4E013863 for ; Wed, 27 Feb 2019 11:50:10 -0800 Received: from mail01.blueorigin.com (MAIL01.blueorigin.com [10.1.1.45]) by quarantine.blueorigin.com with ESMTP id 2qww0h878q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 27 Feb 2019 11:50:09 -0800 Received: from MAIL01.blueorigin.com (10.1.1.45) by MAIL01.blueorigin.com (10.1.1.45) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 27 Feb 2019 11:50:09 -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; Wed, 27 Feb 2019 11:50:09 -0800 From: Jeff Wandling To: "gdb@sourceware.org" Subject: Debugging big-endian ARM target from little-endian host Date: Wed, 27 Feb 2019 19:50:00 -0000 Message-ID: <42ffc1dbeae74ebfb7b29787a0ad4c32@MAIL01.blueorigin.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-02/txt/msg00076.txt.bz2 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. The symptom/problem: When the target firmware is compiled for big-endian, and when JLinkGDBServe= r is running such that the target is big-endian, then when debugging with g= db 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 de= bug 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 fu= nctions 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, et= c..) 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=3Dx86_64-linux-gnu --target=3Darm-none-eabi --with-auto-load-dir=3D:/auto-load --with-auto-load-safe-path=3D:/auto-load --with-expat --with-gdb-datadir=3D/usr/lib/arm-none-eabi/share/gdb --with-jit-reader-dir=3D/usr/lib/lib/gdb --without-libunwind-ia64 --without-lzma --without-babeltrace --without-intel-pt --disable-libmcheck --without-mpfr --without-guile --with-separate-debug-dir=3D/usr/lib/lib/debug --with-system-gdbinit=3D/usr/lib/arm-none-eabi/lib/gdbinit Data and explanation: Suppose the firmware has a function at physical address 0x0000003C (somewh= ere 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 th= e 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=3Dx86_64-linux-gnu --target=3Darm-none-e= abi". Type "show configuration" for configuration details. For bug reporting instructions, please see: =2E 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 add= ress where the function is not located.. The function is at physical addres= s 0x3C. (gdb) monitor regs PC =3D 3C000000, CPSR =3D 000003D3 (SVC mode, ARM FIQ dis. IRQ dis.) R0 =3D 00173180, R1 =3D FFFFFF48, R2 =3D 00000000, R3 =3D D3D3E1AB R4 =3D 00000000, R5 =3D 08000B60, R6 =3D 00000000, R7 =3D 0800013F USR: R8 =3D52894D31, R9 =3D084C44C1, R10=3D8D206C51, R11 =3D58311700, R12 = =3DAC0C7CD7 R13=3D08000BA0, R14=3D08000137 FIQ: R8 =3D180A8884, R9 =3D00200200, R10=3D97D50C37, R11 =3D081E1C10, R12 = =3D18A40002 R13=3D00008000, R14=3D9167F273, SPSR=3D2E0008E8 SVC: R13=3D04A9A810, R14=3D00000040, SPSR=3D2E0018E8 ABT: R13=3D2E6FA985, R14=3D3C000004, SPSR=3D00000393 IRQ: R13=3D2067F940, R14=3D0D044C2C, SPSR=3D2E0018E9 UND: R13=3D01004080, R14=3D00000008, SPSR=3D0000039B OK, so to diagnose, I retried the test, but this time recompiling for littl= e-endian and setup JLinkGDBServer for little endian: Results are a little better. I can step next, but cannot step into: 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=3Dx86_64-linux-gnu --target=3Darm-none-e= abi". Type "show configuration" for configuration details. For bug reporting instructions, please see: =2E 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 ?? () (gdb) file image.elf A program is being debugged already. Are you sure you want to change the file? (y or n) y Load new symbol table from "image.elf"? (y or n) y Reading symbols from image.elf...done. Resetting target (gdb) load Loading section .text, size 0x4760 lma 0x20 Loading section .rodata, size 0x200 lma 0x4780 Start address 0x3c, load size 18784 Transfer rate: 6114 KB/sec, 6261 bytes/write. (gdb) b _c_int00 Breakpoint 1 at 0x3c: file source/HL_sys_startup.c, line 88. (gdb) c Continuing. Breakpoint 1, _c_int00 () at source/HL_sys_startup.c:88 88 _coreInitRegisters_(); (gdb) disassemble _coreInitRegisters_ Dump of assembler code for function _coreInitRegisters_: 0x00004058 : mov r0, lr 0x0000405c : mov r1, #0 0x00004060 : mov r2, #0 0x00004064 : mov r3, #0 0x00004068 : mov r4, #0 0x0000406c : mov r5, #0 0x00004070 : mov r6, #0 0x00004074 : mov r7, #0 0x00004078 : mov r8, #0 0x0000407c : mov r9, #0 0x00004080 : mov r10, #0 0x00004084 : mov r11, #0 0x00004088 : mov r12, #0 0x0000408c : mov sp, #0 0x00004090 : mrs r1, CPSR 0x00004094 : msr SPSR_fsxc, r1 0x00004098 : cps #17 0x0000409c : mov lr, r0 0x000040a0 : mov r8, #0 0x000040a4 : mov r9, #0 0x000040a8 : mov r10, #0 0x000040ac : mov r11, #0 0x000040b0 : mov r12, #0 0x000040b4 : mrs r1, CPSR 0x000040b8 : msr SPSR_fsxc, r1 0x000040bc : cps #18 0x000040c0 : mov lr, r0 0x000040c4 : mrs r1, CPSR 0x000040c8 : msr SPSR_fsxc, r1 0x000040cc : cps #23 0x000040d0 : mov lr, r0 0x000040d4 : mrs r1, CPSR 0x000040d8 : msr SPSR_fsxc, r1 0x000040dc : cps #27 0x000040e0 : mov lr, r0 0x000040e4 : mrs r1, CPSR 0x000040e8 : msr SPSR_fsxc, r1 0x000040ec : cps #31 0x000040f0 : mov lr, r0 0x000040f4 : mrs r1, CPSR 0x000040f8 : msr SPSR_fsxc, r1 0x000040fc : mrc 15, 0, r2, cr1, cr0, {2} 0x00004100 : orr r2, r2, #15728640 ; 0xf00000 0x00004104 : mcr 15, 0, r2, cr1, cr0, {2} 0x00004108 : mov r2, #1073741824 ; 0x40000000 0x0000410c : vmsr fpexc, r2 --Type for more, q to quit, c to continue without paging--q Quit (gdb) b *0x4058 Breakpoint 2 at 0x4058: file source/HL_sys_core.s, line 50. (gdb) n // I would have expected the breakpoint at 0x4058 to be hit since it's afte= r 0x4164, where the 'next' progressed to. 91 _coreInitStackPointer_(); (gdb) disassemble _coreInitStackPointer_ Dump of assembler code for function _coreInitStackPointer_: 0x00004164 : cps #17 0x00004168 : ldr sp, [pc, #48] ; 0x41a0 0x0000416c : cps #18 0x00004170 : ldr sp, [pc, #44] ; 0x41a4 0x00004174 : cps #19 0x00004178 : ldr sp, [pc, #28] ; 0x419c 0x0000417c : cps #23 0x00004180 : ldr sp, [pc, #32] ; 0x41a8 0x00004184 : cps #27 0x00004188 : ldr sp, [pc, #28] ; 0x41ac 0x0000418c : cps #31 0x00004190 : ldr sp, [pc] ; 0x4198 0x00004194 : bx lr End of assembler dump. (gdb) si 96 rstSrc =3D getResetSource(); // I would have expected it step into _coreInitStackPointer_, rather it ste= pped over it. (gdb) list 91 _coreInitStackPointer_(); 92 93 /* Reset handler: the following instructions read from the= system exception status register 94 * to identify the cause of the CPU reset. 95 */ 96 rstSrc =3D getResetSource(); 97 switch(rstSrc) 98 { 99 case POWERON_RESET: 100 /* Initialize L2RAM to avoid ECC errors right after powe= r on */ (gdb)