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 C09CF3858C3A for ; Tue, 9 May 2023 15:15:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C09CF3858C3A 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 6ACA3313ACB3; Tue, 9 May 2023 17:15:02 +0200 (CEST) Received: by r6.localdomain (Postfix, from userid 1000) id 9081534006A; Tue, 9 May 2023 17:15:00 +0200 (CEST) Message-ID: Subject: Re: [PATCH 1/5] strip: Adapt src/strip -o -f on mips From: Mark Wielaard To: ying.huang@oss.cipunited.com, elfutils-devel@sourceware.org Date: Tue, 09 May 2023 17:15:00 +0200 In-Reply-To: <20230411081141.1762395-2-ying.huang@oss.cipunited.com> References: <20230411081141.1762395-1-ying.huang@oss.cipunited.com> <20230411081141.1762395-2-ying.huang@oss.cipunited.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.1 (3.48.1-1.fc38) MIME-Version: 1.0 X-Spam-Status: No, score=-3028.6 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, On Tue, 2023-04-11 at 16:12 +0800, Ying Huang wrote: > From: Ying Huang >=20 > In mips64 little-endian, r_info consists of four byte fields(contains > three reloc types) and a 32-bit symbol index. In order to adapt > GELF_R_SYM and GELF_R_TYPE, need convert raw data to get correct symbol > index and type. Is there a spec that describes this? I see you adjusted elf.h to include: +#define ELF64_MIPS_R_TYPE(i) ((i) & 0xff) +#define ELF64_MIPS_R_TYPE2(i) (((i) >> 8) & 0xff) +#define ELF64_MIPS_R_TYPE3(i) (((i) >> 16) & 0xff) And various new relocation types for MIPS variants. Our elf.h comes from the glibc project. Have you also submitted these changes to libc-alpha@sourceware.org ? > libelf/elf_getdata.c: Some eu-utils use read-mmap method to map file, > so we need to malloc and memcpy raw data to avoid segment fault. After > modification, the correct value are saved in the malloced memory not in > process address space. Where do these segfaults show up? > libelf/elf_updata.c: Because we converted the relocation info in mips > order when we call elf_getdata.c, so we need to convert the modified data > in original order bits before writing the data to the file. It feels like this is in the wrong place and doesn't take into account whether the program itself is running on a big or little endian machine. Maybe I am misunderstanding why this conversion is needed always. But I would have expected a specific conversion function for MIPS for ELF_T_REL and/or ELF_T_RELA (which are currently generic). Cheers, Mark