From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 5E1A6385742C; Tue, 14 Jun 2022 09:03:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5E1A6385742C Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 7689F1F460; Tue, 14 Jun 2022 09:03:22 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 58898139EC; Tue, 14 Jun 2022 09:03:22 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id fhyIFNpOqGKzLgAAMHmgww (envelope-from ); Tue, 14 Jun 2022 09:03:22 +0000 Message-ID: <7449d20d-d35b-dbf0-e01a-39940dd914af@suse.de> Date: Tue, 14 Jun 2022 11:03:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH][gdb] Fix fbsd core matching Content-Language: en-US To: Alan Modra , John Baldwin Cc: gdb-patches@sourceware.org, binutils@sourceware.org References: <20220609085842.GA32249@delia.home> <790e4948-9a70-a7c7-f562-a2bf16a54506@FreeBSD.org> From: Tom de Vries In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-13.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, 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 09:03:33 -0000 On 6/14/22 02:05, Alan Modra wrote: > 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. > I've run the gdb testsuite on x86_64-linux with native and target board unix-/m32, no regressions and originally reported FAIL fixed. Thanks, - Tom > 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 >