From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from t03.bc.larksuite.com (t03.bc.larksuite.com [209.127.231.31]) by sourceware.org (Postfix) with UTF8SMTPS id D0170385735C for ; Tue, 16 May 2023 06:39:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D0170385735C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=oss.cipunited.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=oss.cipunited.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=s1; d=oss-cipunited-com.20200927.dkim.feishu.cn; t=1684219137; h=from:subject:mime-version:from:date:message-id:subject:to:cc: reply-to:content-type:mime-version:in-reply-to:message-id; bh=qyWRAxticO2ipFnPdmN3iqW2YAMfc2HZPC7n1UQ1lEY=; b=lmj73OTaKTdDF7rD9Tyx5dBwH9TedobCtdi7aDDQBz5xyq2SQR2BCkBXaP+JaIogrjvqyj GodPjv0hCggqposDMqWgIi1Ht/8GHSITiSnFlxYJaNWHvToW1FgAsg5BDoMJIzrq9NWz1z sdtCqE4qhDPKDnQ2luNonJD+qkkvYrLkJ3DRzQmiUJ/ZNsgb1AgfNl+4Or9AZKRNhti6GE ygefka+bzYtU/wtntqJ5iuWjwcFwhiJDfxZTWPD/cesOuf9ou75+p6Daz1gxkoIHuoeRQt +qems3ubeZPXhQI0fS18CVoVIuYYgNirHvYQ1wIQU5GcQHysgjjlfmYznPCe3A== Cc: Date: Tue, 16 May 2023 14:38:45 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Content-Transfer-Encoding: 8bit X-Lms-Return-Path: In-Reply-To: References: <20230411081141.1762395-1-ying.huang@oss.cipunited.com> <20230411081141.1762395-2-ying.huang@oss.cipunited.com> Content-Type: multipart/alternative; boundary=10be23dc4d424164c6f5806ad1e2df5424a3b5aea1e06743071af8cb0984 Content-Language: en-US To: "Mark Wielaard" , From: "Ying Huang" Subject: Re: [PATCH 1/5] strip: Adapt src/strip -o -f on mips Message-Id: <9035496c-3414-ac66-bd86-281592aa2a77@oss.cipunited.com> Mime-Version: 1.0 X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,HTML_MESSAGE,HTML_NONELEMENT_30_40,NICE_REPLY_A,SPF_HELO_NONE,SPF_NONE,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 List-Id: --10be23dc4d424164c6f5806ad1e2df5424a3b5aea1e06743071af8cb0984 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Hi, =E5=9C=A8 2023/5/9 23:15, Mark Wielaard =E5=86=99=E9=81=93: > Hi, > > On Tue, 2023-04-11 at 16:12 +0800, Ying Huang wrote: >> From: Ying Huang >> >> 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? =C2=A0=C2=A0=C2=A0 references: =C2=A0=C2=A0=C2=A0 https://www.linux-mips.org/pub/linux/mips/doc/ABI/elf64-= 2.4.pdf =C2=A0=C2=A0=C2=A0 Page40 && Page41 > > 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 ? =C2=A0=C2=A0=C2=A0 Has submitted. =C2=A0=C2=A0=C2=A0 https://sourceware.org/pipermail/libc-alpha/2023-May/148= 026.html =C2=A0=C2=A0=C2=A0 https://sourceware.org/pipermail/libc-alpha/2023-May/148= 112.html > >> 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. =C2=A0=C2=A0=C2=A0 Has tested on big/little endian machine with big/little = endian ELF file, all were OK. > 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 =C2=A0=C2=A0=C2=A0 1.Considering that some people directly use the original= data instead of the interface function gelf_getrela; =C2=A0=C2=A0=C2=A0 2.Because there is only one parameter, so can not modify= the macro ELF64_R_TYPE=EF=BC=9B =C2=A0=C2=A0=C2=A0 3.If the mips interface function is added, other package= s using libelf will not be compatible with mips, and the place where gelf_g= etrela is used need be modified. =C2=A0=C2=A0=C2=A0 Where do you think is the most suitable place to do mips= conversion? Thanks, Ying= --10be23dc4d424164c6f5806ad1e2df5424a3b5aea1e06743071af8cb0984--