From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 6BA3B3858D37 for ; Tue, 1 Nov 2022 21:01:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6BA3B3858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from reform (deer0x15.wildebeest.org [172.31.17.151]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id C21903061FA5; Tue, 1 Nov 2022 22:01:40 +0100 (CET) Received: by reform (Postfix, from userid 1000) id 535072E80F8E; Tue, 1 Nov 2022 22:01:40 +0100 (CET) Date: Tue, 1 Nov 2022 22:01:40 +0100 From: Mark Wielaard To: Shahab Vahedi Cc: "elfutils-devel@sourceware.org" , Claudiu Zissulescu Subject: Re: [PATCH] Add support for ARCv2 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3032.4 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_ASCII_DIVIDERS,KAM_DMARC_STATUS,KAM_NUMSUBJECT,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Shahab, On Mon, Oct 31, 2022 at 02:54:33PM +0000, Shahab Vahedi via Elfutils-devel wrote: > Thank you for response. First and foremost, there is a second iteration of the > patch [1]. I don't want you, or anybody else, waste time looking into v1. The > changes from v1 have been mentioned at the end of v2 commit message. Thanks. > There is a QEMU target [2]. However, this patch adds a minimal support for ARC. > I'm not quite sure building and running elfutils natively for ARC would test > much at this point. That's why I tested with an x86_64 build with ARC target > support: master + patch -> make check > > Unfortunately, there is no machine in GCC's compile farm. There does exist a > pre-built compiler [3] and a repo [4] though. It might be good to add some tests that can be run on a non ARC architecture just so people can check they didn't break something. See e.g. tests/run-strip-reloc.sh tests/run-allregs.sh or tests/run-addrcfi.sh which take small prebuild object files. > >> ARC target related > >> macros has been added to libelf/elf.h. However, there a few changes > >> on existing ARC macros to correct them and be in sync with binutils. > > > > We normally sync with the glibc elf.h, have you submitted these > > changes to libc-alpha? > > No, but I intend to. In a v2 of the patch [1], I also have added ChangeLog > entries. It must be easier now to quickly figure out what has changed and > if it's OK or not. Thanks. Normally we wait syncing the elf.h file once a patch lands in glibc. > >> There are no regressions in tests for an x86_64 build. > >> > >> ========================================== > >> elfutils 0.187: tests/test-suite.log > >> ========================================== > >> > >> .. contents:: :depth: 2 > >> > >> FAIL: run-backtrace-native-core.sh > >> ================================== > >> > >> backtrace: No modules recognized in core file > >> backtrace-child-core.8740: no main > >> rmdir: failed to remove 'test-8732': Directory not empty > >> FAIL run-backtrace-native-core.sh (exit status: 1) > >> > >> FAIL: run-backtrace-native-core-biarch.sh > >> ========================================= > >> > >> backtrace: No modules recognized in core file > >> backtrace-child-biarch-core.8763: no main > >> rmdir: failed to remove 'test-8755': Directory not empty > >> FAIL run-backtrace-native-core-biarch.sh (exit status: 1) > > > > These two need abi_cfi hooks to describe the DWARF CFI needed to > > unwind. > > To be clear, these are the test results on a build without the patch AND > with the patch. I'm not sure why it happens even without the patch on > my system. If you want, I can file a bug report with more details. Aha, sorry, I missed this was on x86_64. That is indeed odd. If you could file a bug report with your environment where this fails that would be good. Thanks, Mark