From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by sourceware.org (Postfix) with ESMTPS id C0AD93850221; Tue, 14 Jun 2022 00:05:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C0AD93850221 Received: by mail-pj1-x1034.google.com with SMTP id t3-20020a17090a510300b001ea87ef9a3dso7532138pjh.4; Mon, 13 Jun 2022 17:05:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=35xqzeD+v6eYmb+y/ARzZT7gh72ji/Dd5olGqWb1niY=; b=1IiTP9j5wpK7QNeSU0BJSO7f0kkFpBMsgZunsb1NXlouBquyDeZ5O+ExEK4rBVnkVh MAplxpFavJHN57CAmw8AzaFMUVmFe3X4Uc80gKNanRnk7EqdnIrWScOIkD5g5Itl4hb4 DOTVvTirNK2q5AG64J4rNOPyCVEwyG9bQYtJYNrKQGE9HtSIDtOI0a/TMok5aH5fILOR jAnQl71VC0RkC0BQCexLJeQDuItdg5AB2exFw5L8baKpHWWpeCQ4T/vcA2DZSnVdb2r1 vTyW7q38xpuOr1R/dcSDQO3YlrMwuYQ5pHwoOTwciuwW5DnWON+g0RueES2ZH8YKz5c8 sOfA== X-Gm-Message-State: AOAM531KrwN7N/cg+ek5FpQ+0za5gErv4C5mWnz1zhVr1gylu344lKvG X3h2tDWwx3CfglZnDGp6U+0= X-Google-Smtp-Source: AGRyM1vJYEHO6rzldKNTKWS4GtnhodtycHvzzowsVR1P8/eN//KVRgYTsBRRHGtnvtmX7wgI7DAfLQ== X-Received: by 2002:a17:902:b494:b0:167:97e4:8a1a with SMTP id y20-20020a170902b49400b0016797e48a1amr1436697plr.83.1655165150760; Mon, 13 Jun 2022 17:05:50 -0700 (PDT) Received: from squeak.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id q7-20020aa79607000000b0051b915c1a47sm6015625pfg.113.2022.06.13.17.05.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jun 2022 17:05:49 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id E0F1F1140197; Tue, 14 Jun 2022 09:35:46 +0930 (ACST) Date: Tue, 14 Jun 2022 09:35:46 +0930 From: Alan Modra To: John Baldwin Cc: Tom de Vries , gdb-patches@sourceware.org, binutils@sourceware.org Subject: Re: [PATCH][gdb] Fix fbsd core matching Message-ID: References: <20220609085842.GA32249@delia.home> <790e4948-9a70-a7c7-f562-a2bf16a54506@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <790e4948-9a70-a7c7-f562-a2bf16a54506@FreeBSD.org> X-Spam-Status: No, score=-3037.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2022 00:05:54 -0000 On Thu, Jun 09, 2022 at 08:59:37AM -0700, John Baldwin wrote: > On 6/9/22 1:58 AM, Tom de Vries via Gdb-patches wrote: > > Hi, > > > > With an --enable-targets=all build and target board unix/-m32 I run into a > > FAIL in test-case gdb.base/corefile.exp: > > ... > > (gdb) file outputs/gdb.base/corefile/corefile^M > > Reading symbols from outputs/gdb.base/corefile/corefile...^M > > (gdb) core-file outputs/gdb.base/corefile/corefile.core^M > > warning: core file may not match specified executable file.^M > > [New LWP 12011]^M > > Core was generated by `outputs/gdb.base/corefile/co'.^M > > Program terminated with signal SIGABRT, Aborted.^M > > (gdb) FAIL: gdb.base/corefile.exp: core-file warning-free > > ... > > > > The warning is there because of this mismatch between core and exec: > > ... > > (gdb) p core_bfd->xvec > > $3 = (const struct bfd_target *) 0x20112a0 > > (gdb) p exec_bfd->xvec > > $4 = (const struct bfd_target *) 0x2010b00 > > ... > > > > In the exec case, the detected architecture is i386_elf32_vec because this bit > > of code in elfcode.h:elf_object_p(): > > ... > > if (ebd->elf_machine_code != EM_NONE > > && i_ehdrp->e_ident[EI_OSABI] != ebd->elf_osabi > > && ebd->elf_osabi != ELFOSABI_NONE) > > goto got_wrong_format_error; > > ... > > prevents i386_elf32_fbsd from matching. > > > > Fix the core matching by copying that code to elfcore.h:elf_core_file_p(). > > > > Tested on x86_64-linux. > > > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29227 > > > > Any comments? Looks good. > Looking at elfcore.h, it seems to have not gotten changes made to elfcode.h over > time and is a bit rotted. I suspect that all of changes made in commit 0aabe54e6222 > that added these lines in elfcode.h (along with several other changes) need to > be applied to this function in elfcore.h, not just adding these lines. Yes, the commit 0aabe54e6222 changes likely should go in too. I'm a little wary of adding all the sanity checks to elf_core_file_p since that might result in some core files not being recognised at all. For example, despite the FIXME I'd guess leaving out the EI_VERSION check was deliberate. The following seems reasonable to me. Please test. diff --git a/bfd/elfcore.h b/bfd/elfcore.h index 809f6711aed..59b73bd57de 100644 --- a/bfd/elfcore.h +++ b/bfd/elfcore.h @@ -149,37 +149,14 @@ elf_core_file_p (bfd *abfd) && (ebd->elf_machine_alt1 == 0 || i_ehdrp->e_machine != ebd->elf_machine_alt1) && (ebd->elf_machine_alt2 == 0 - || i_ehdrp->e_machine != ebd->elf_machine_alt2)) - { - const bfd_target * const *target_ptr; - - if (ebd->elf_machine_code != EM_NONE) - goto wrong; - - /* This is the generic ELF target. Let it match any ELF target - for which we do not have a specific backend. */ + || i_ehdrp->e_machine != ebd->elf_machine_alt2) + && ebd->elf_machine_code != EM_NONE) + goto wrong; - for (target_ptr = bfd_target_vector; *target_ptr != NULL; target_ptr++) - { - const struct elf_backend_data *back; - - if ((*target_ptr)->flavour != bfd_target_elf_flavour) - continue; - back = xvec_get_elf_backend_data (*target_ptr); - if (back->s->arch_size != ARCH_SIZE) - continue; - if (back->elf_machine_code == i_ehdrp->e_machine - || (back->elf_machine_alt1 != 0 - && i_ehdrp->e_machine == back->elf_machine_alt1) - || (back->elf_machine_alt2 != 0 - && i_ehdrp->e_machine == back->elf_machine_alt2)) - { - /* target_ptr is an ELF backend which matches this - object file, so reject the generic ELF target. */ - goto wrong; - } - } - } + if (ebd->elf_machine_code != EM_NONE + && i_ehdrp->e_ident[EI_OSABI] != ebd->elf_osabi + && ebd->elf_osabi != ELFOSABI_NONE) + goto wrong; /* If there is no program header, or the type is not a core file, then we are hosed. */ @@ -199,6 +176,9 @@ elf_core_file_p (bfd *abfd) Elf_Internal_Shdr i_shdr; file_ptr where = (file_ptr) i_ehdrp->e_shoff; + if (i_ehdrp->e_shoff < sizeof (x_ehdr)) + goto wrong; + /* Seek to the section header table in the file. */ if (bfd_seek (abfd, where, SEEK_SET) != 0) goto fail; > I've cc'd Alan who made that commit above to elfcore.h. There also seem to be > some other inconsistencies between the functions in elfcore.h and and elfcode.h > and perhaps the common functionality in these functions could be refactored > into a separate function to avoid the code duplication? > > Note that the issue isn't really FreeBSD specific, I just suspect that the FreeBSD > i386 vec happens to be sorted first in the list for some reason. > > Thanks, > > - Tom > > > > [gdb] Fix fbsd core matching > > > > --- > > bfd/elfcore.h | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/bfd/elfcore.h b/bfd/elfcore.h > > index 809f6711aed..4ce81e2e383 100644 > > --- a/bfd/elfcore.h > > +++ b/bfd/elfcore.h > > @@ -272,6 +272,11 @@ elf_core_file_p (bfd *abfd) > > && ebd->elf_machine_code != EM_NONE) > > goto fail; > > + if (ebd->elf_machine_code != EM_NONE > > + && i_ehdrp->e_ident[EI_OSABI] != ebd->elf_osabi > > + && ebd->elf_osabi != ELFOSABI_NONE) > > + goto fail; > > + > > /* Let the backend double check the format and override global > > information. We do this before processing the program headers > > to allow the correct machine (as opposed to just the default > > > -- > John Baldwin -- Alan Modra Australia Development Lab, IBM