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 646E23858D28 for ; Tue, 1 Aug 2023 13:14:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 646E23858D28 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 r6.localdomain (82-217-174-174.cable.dynamic.v4.ziggo.nl [82.217.174.174]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 26DD93000913; Tue, 1 Aug 2023 15:14:43 +0200 (CEST) Received: by r6.localdomain (Postfix, from userid 1000) id B73C9340276; Tue, 1 Aug 2023 15:14:41 +0200 (CEST) Message-ID: <9c8813809fafe132a156e293637c47fdd2fe5863.camel@klomp.org> Subject: Re: [PATCH 2/5] readelf: Adapt src/readelf -h/-S/-r/-w/-l/-d/-a on mips From: Mark Wielaard To: Ying Huang Cc: elfutils-devel@sourceware.org, yunqiang.su@oss.cipunited.com Date: Tue, 01 Aug 2023 15:14:41 +0200 In-Reply-To: <18ad5b3f-a640-7923-3ff5-0c52e66a25a1@oss.cipunited.com> References: <20230411081141.1762395-1-ying.huang@oss.cipunited.com> <20230411081141.1762395-3-ying.huang@oss.cipunited.com> <3a59ea20739cde776aad7945ca4cc09055e1db6f.camel@klomp.org> <18ad5b3f-a640-7923-3ff5-0c52e66a25a1@oss.cipunited.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) MIME-Version: 1.0 X-Spam-Status: No, score=-3027.8 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 Ying, On Tue, 2023-07-25 at 16:15 +0800, Ying Huang wrote: > In file common-reloc.c, hook functions reloc_type_check/reloc_type_use/re= loc_type_name have these codes: >=20 > #ifdef RELOC_TYPE_ID > =C2=A0 reloc =3D RELOC_TYPE_ID (reloc); > #endif >=20 > And the macro RELOC_TYPE_ID was defined in file backends/sparc_init.c: >=20 > /* In SPARC some relocations use the most significative 24 bits of the > =C2=A0=C2=A0 r_type field to encode a secondary addend.=C2=A0 Make sure t= he routines > =C2=A0=C2=A0 in common-reloc.c acknowledge this.=C2=A0 */ > #define RELOC_TYPE_ID(type) ((type) & 0xff) >=20 > The contents of macro RELOC_TYPE_ID were same as ELF64_MIPS_R_TYPE(new ad= ded), so my view is did not add new hook for mips, if we can do like sparc? Sorry, hadn't seen this message before. But yes, if you can do like sparc and define RELOC_TYPE_ID then that would be simpler than creating a full new HOOK for reloc_type_check. Cheers, Mark