From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) by sourceware.org (Postfix) with ESMTPS id 6B3993954C07 for ; Tue, 6 Oct 2020 16:59:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6B3993954C07 Received: by mail-pg1-x543.google.com with SMTP id g29so8319271pgl.2 for ; Tue, 06 Oct 2020 09:59:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5i6Nb8rY/lNrIEkDgCvzi40eXK/FF+pm6+WzhPKVqVk=; b=rEWd0aje2E/Zvg4HVdx4rplw4CZmBbFqoZFEm1KFxDFIj6e2/bv2EMnB2O7U0GbvLG ybiuDn097+LI+GuP5K/OKruZba//S1h/Vmn3eoMThe1upDC8R9ajsGvGjmoOA8LfMzEE eswu9Y4O9P9yv/e1syNKgFbgJC++U/gxGsIppBtOofOX1zsfuZSm4SUo8FMscHyoSeYO gkkVpNLE2nqpOifGKYTv35Kr4ke7d4vWFNJaMwWftcDwGBtNEn5FuzPNVTAFGFNk/sno 7v2VFg62UAznXgIDJjBr3toELfeZTuiPhP3yWUdnyaGbTgmhJiGxRR2SBcGCD84riJM0 GoRA== X-Gm-Message-State: AOAM530McY/kXKE+OJaCfjyYIQkcnxEZ0/kePImem271Yua+0j175Hfu J/1NYap9HgLzS6hr9bp71Q7tnmzKfp4LyY4HyyxLtkxz6D3tGQ== X-Google-Smtp-Source: ABdhPJxnYYyZMiW1I7hLETdUGvv8+v8eKZqRiT+SjAKP6hFHp8RIivhkBGbO1FxYm5PDNtfFNjw9xJ9hp2/IXnI+QBs= X-Received: by 2002:aa7:8d15:0:b029:142:2501:39fe with SMTP id j21-20020aa78d150000b0290142250139femr5409719pfe.77.1602003584172; Tue, 06 Oct 2020 09:59:44 -0700 (PDT) MIME-Version: 1.0 References: <20201003181451.GA2211174@google.com> <9d2c488d-8763-c17d-e93a-1dbad80bc293@simark.ca> In-Reply-To: <9d2c488d-8763-c17d-e93a-1dbad80bc293@simark.ca> From: Paul Mathieu Date: Tue, 6 Oct 2020 09:59:32 -0700 Message-ID: Subject: Re: [PATCH v2] gdb: add support for handling core dumps on arm-none-eabi To: Simon Marchi , Alan Hayward Cc: Luis Machado , gdb-patches@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.9 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 16:59:47 -0000 On Tue, Oct 6, 2020 at 7:29 AM Simon Marchi wrote: > On 2020-10-06 8:45 a.m., Luis Machado wrote: > > On 10/6/20 1:32 AM, Paul Mathieu via Gdb-patches wrote: > >> Seems to me like current_inferior()->gdbarch is returning the > >> arm-linux gdbarch. Maybe this is because the main .elf executable > >> itself is recognized as arm-linux? I have virtually no control over > >> the executable image, so I would not be able to insert the same kind > >> of note section as I would for a core file to differentiate it from > >> arm-linux executables. > > > > I think there may be enough hints here and there to be able to tell > > those apart via an heuristic. Isn't there a particular note section or > > flag that you can fetch and tell it is not a Linux executable but a > > bare-metal one? I did a quick comparison between two executables. The first one is taken from the armhf debian distribution. The second one is for my bare-metal cortex-m4 target. =E2=9E=9C bin readelf -h screen ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: DYN (Shared object file) Machine: ARM Version: 0x1 Entry point address: 0x6271 Start of program headers: 52 (bytes into file) Start of section headers: 310736 (bytes into file) Flags: 0x5000400, Version5 EABI, hard-float A= BI Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 9 Size of section headers: 40 (bytes) Number of section headers: 28 Section header string table index: 27 =E2=9E=9C bin readelf -h my_bare_metal_stuff.elf ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: ARM Version: 0x1 Entry point address: 0xc018011 Start of program headers: 52 (bytes into file) Start of section headers: 49269716 (bytes into file) Flags: 0x5000400, Version5 EABI, hard-float A= BI Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 39 Size of section headers: 40 (bytes) Number of section headers: 76 Section header string table index: 75 The ELF header does not help us much, except that the linux executable is marked as a DYN object, probably because it's dynamically linked(?). I assume that statically linked executables will then use the EXEC ELF type, which means I can't use that. In particular, the OS/ABI section is identical. That's a quirk of the enum, where SYSV and NONE have the same value. Yikes. There are also some notes in the linux binary that look nice: =E2=9E=9C bin readelf --notes screen Displaying notes found in: .note.gnu.build-id Owner Data size Description GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstrin= g) Build ID: 76c649229b0402d6a0d1f65c3925e85fcb18e79d Displaying notes found in: .note.ABI-tag Owner Data size Description GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag) OS: Linux, ABI: 3.2.0 My own bare-metal executable contains no notes at all. Again, here, I'm not sure how widespread these notes are, and if linux really requires them to run the binary or not. As the note name suggests, it looks like a GNU extension, which implies that it's not mandatory? I found one more thing, trying to find differences between the 2 files. =E2=9E=9C bin readelf --arch-specific screen Attribute Section: aeabi File Attributes Tag_CPU_name: "7-A" Tag_CPU_arch: v7 Tag_CPU_arch_profile: Application Tag_ARM_ISA_use: Yes Tag_THUMB_ISA_use: Thumb-2 Tag_FP_arch: VFPv3-D16 Tag_ABI_PCS_wchar_t: 4 Tag_ABI_FP_rounding: Needed Tag_ABI_FP_denormal: Needed Tag_ABI_FP_exceptions: Needed Tag_ABI_FP_number_model: IEEE 754 Tag_ABI_align_needed: 8-byte Tag_ABI_align_preserved: 8-byte, except leaf SP Tag_ABI_enum_size: int Tag_ABI_VFP_args: VFP registers Tag_CPU_unaligned_access: v6 =E2=9E=9C bin readelf --arch-specific my_bare_metal_stuff.elf Attribute Section: aeabi File Attributes Tag_CPU_name: "8-M.MAIN" Tag_CPU_arch: v8-M.mainline Tag_CPU_arch_profile: Microcontroller Tag_THUMB_ISA_use: Yes Tag_FP_arch: FPv5/FP-D16 for ARMv8 Tag_ABI_PCS_wchar_t: 4 Tag_ABI_FP_denormal: Needed Tag_ABI_FP_exceptions: Needed Tag_ABI_FP_number_model: IEEE 754 Tag_ABI_align_needed: 8-byte Tag_ABI_enum_size: small Tag_ABI_VFP_args: VFP registers Tag_CPU_unaligned_access: v6 Tag_DSP_extension: Allowed The Tag_CPU_arch_profile value is different, and looks like I could use tha= t. Alan, would you say this tag is meaningful & reliable? > Just so we are on the same page as to why this is happening, can you try > to step into function "gdbarch_info_fill" while you're executable is > loaded? > > What I think is happening is that gdbarch_lookup_osabi returns > GDB_OSABI_UNKNOWN, because no sniffer identified it. > > So the default osabi of your build gets used instead: > > /* From the configured default. */ > #ifdef GDB_OSABI_DEFAULT > if (info->osabi =3D=3D GDB_OSABI_UNKNOWN) > info->osabi =3D GDB_OSABI_DEFAULT; > #endif That looks right. `gdbarch_lookup_osabi` indeed returns GDB_OSABI_UNKNOWN. Here's what I get in gdb after loading the main file: (gdb) show osabi The current OS ABI is "auto" (currently "GNU/Linux"). The default OS ABI is "GNU/Linux". > So indeed, if there was a sniffer identifying the binary as a "none" > osabi, it would probably work. The problem is, how do you write such a > sniffer? It's easy to check for a Linux binary, you check for the os > abi ELF note. As mentioned above, I looked into ELF file differences between arm-linux and arm-none and couldn't find anything of substance. Am I missing something? > But how do you identify a "none" binary? You would have > to check that's it's not a Linux binary, not FreeBSD binary, not a > Windows binary, etc. Agreed. There seems to be a sniffer for PikeOS, which looks for a specific symbol in the symbol table. There is a comment in there saying that the BFD target is otherwise just standard ELF. I'm afraid that if I was to use a trick, such as the Tag_CPU_arch_profile mentioned above, I would prevent some other targets from working properly. > I don't really like the idea of having a "default" osabi that we fall > back on, because it can just silently get it wrong, like in this case. > I think it would make more sense for the fall back to be "none". > Because it's hard to detect a "none" binary, as explained above. I looked into configure.tgt, and it looks like default osabi is only set for targets that have -linux in them. I'm building gdb with `./configure --enable-targets=3Darm-none-eabi`, should that help? In my case, the resulting gdb program still crashes with the same message. Interestingly, it also prints out a warning: warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration of GDB. Attempting to continue with the default armv8-m.main settings. I think in this case, the fact that it uses linux as a default osabi could be a bug? In the general case, a multiarch gdb would require `set osabi none` to work, but that's already better than nothing, IMO. > In the mean time, for your testing, you can force the osabi to none by > using "set osabi none" prior to loading anything. Yes, that works fine. Thanks! I'll send a revised patch that uses GDB_OSABI_NONE shortly. Super thanks for the great feedback! Paul