From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by sourceware.org (Postfix) with ESMTPS id 7C1E93853D4C for ; Thu, 17 Nov 2022 18:51:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7C1E93853D4C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x52f.google.com with SMTP id s5so3863103edc.12 for ; Thu, 17 Nov 2022 10:51:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=WpX/2/sEO1ZpiRPjw+sjLVD2Y1yOTP1Vtw8RH97mAM8=; b=jsnMV/fhorwY7QHVGxMSapLwdZo+KX+cQBKlJVTHPR5PVZBxwHdJvcRrR2jDljl6Yu QVNL48diFl+p3ts5zuDZL+/vpQJm0wHzSdw6S/6jcRp3Yb8nrbfms0m2NbRyQuOpw+9V kTue2y7ZqXsDw9OSSuyNg/vdfzOKmMZkOP29gCa+94J7gJ557TP5SM5d5gIl5HUzgbpe P7I+1pISW6QH4K9LQaSh8XfEh8nMoCFKUam3We04TqZ8bIRSV/IW2DiGQQhxxh36stUy SIv49rIE1C/BWVzKb2SB3TBgbMqfCKl3ekTzrAGzOZcV4Y3uyXzBJae0GBjfqGb6HUow fENg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WpX/2/sEO1ZpiRPjw+sjLVD2Y1yOTP1Vtw8RH97mAM8=; b=JQ64C3t9CpXV8qth5T76OTO4F8JwhoLPMm9GuqRvSPwZpWw4OKGgfYTGGX+pU5CJ1m IC8pKNS/AyigOGEq0tNmvCbsQBg6yQjvV2v/LFOHnyKKeDCyqZ3Mq9Rh11PKkAFiGtXE hiqjkx37MSOxjdt1dZqJazyAuein2aVeLcD5ZyXOuqC5RwoslBrNY7ArEIjh8UjDrEL5 ue0Dd+hjUunZdpI/SZznuFCj7AYzTzyWJKWYTB3WIVagXlB7oe9XD6pefFASJQfn4vxe L0aQlwANgtJ+DiyUizmy60jcyZMYEC1/LNhi6Lbres2u+e3+IcGVyY8i6c+fIsa/f5qW y8eA== X-Gm-Message-State: ANoB5pkTwo89/qsnsUzDb8aq7qKoJDNdUXWiDluY4TpXQN3FmLKBVnDJ WN1k3HwGZTnIb5UItR+Jnnc/auY0CgA/qYIwIdhgC2O3 X-Google-Smtp-Source: AA0mqf7yOoVSDoHX84LDXFvIMW1/D8BfAuXF4xFqylJcUlb1c7JG+v4vWcIfOAotv8O3WHzsncYFCGKXWUT+TCUA9oc= X-Received: by 2002:aa7:c841:0:b0:45d:2a5:2db8 with SMTP id g1-20020aa7c841000000b0045d02a52db8mr3354046edt.105.1668711088149; Thu, 17 Nov 2022 10:51:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "H.J. Lu" Date: Thu, 17 Nov 2022 10:50:49 -0800 Message-ID: Subject: Re: [PATCH] binutils: partially revert 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8 To: =?UTF-8?B?5b6Q5oyB5oGSIFh1IENoaWhlbmc=?= Cc: "binutils@sourceware.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3015.8 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_LOTSOFHASH,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,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: On Thu, Nov 17, 2022 at 10:28 AM =E5=BE=90=E6=8C=81=E6=81=92 Xu Chiheng wrote: > > No. not using NASM. > > using x86_64-elf-g++ -m32 to generate 32 bit code(elf32). > using x86_64-elf-objcopy to convert it to elf64. > then link the 32 bit code(elf64) with 64 bit code. > This is an unsupported operation. H.J. > > > ________________________________ > From: H.J. Lu > Sent: Friday, November 18, 2022 02:06 > To: =E5=BE=90=E6=8C=81=E6=81=92 Xu Chiheng > Cc: binutils@sourceware.org > Subject: Re: [PATCH] binutils: partially revert 17c6c3b99156fe82c1e637e1a= 5fd9f163ac788c8 > > On Thu, Nov 17, 2022 at 9:44 AM =E5=BE=90=E6=8C=81=E6=81=92 Xu Chiheng vi= a Binutils > wrote: > > > > Phenomenal: In 32 bit and 64 bit mixed code, ld can't do relocation > > for 32 bit code. > > It is caused by commit 17c6c3b99156fe82c1e637e1a5fd9f163ac788c8. > > > > > > > > > > /* src_mask selects the part of the instruction (or data) to be used > > in the relocation sum. If the target relocations don't have an > > addend in the reloc, eg. ELF USE_REL, src_mask will normally equal > > dst_mask to extract the addend from the section contents. If > > relocations do have an addend in the reloc, eg. ELF USE_RELA, this > > field should normally be zero. Non-zero values for ELF USE_RELA > > targets should be viewed with suspicion as normally the value in > > the dst_mask part of the section contents should be ignored. */ > > bfd_vma src_mask; > > > > > > > > Author: Jan Beulich 2021-05-07 18:05:12 > > Committer: Jan Beulich 2021-05-07 18:05:12 > > Parent: 98da05bf2698b55b73453480a3fbb92f163d2c7b (x86: don't mix disp > > and imm processing) > > Child: 4cf88725da1cb503be04d3237354105ec170bc86 ([gdb/symtab] Fix > > infinite recursion in dwarf2_cu::get_builder()) > > Branches: master, test0558-01 and many more (41) > > Follows: gdb-10-branchpoint > > Precedes: binutils-2_37, gdb-11-branchpoint > > > > x86-64/ELF: clear src_mask for all reloc types > > > > x86-64 uses rela relocations. The comment next to the field's decla= ration > > says "Non-zero values for ELF USE_RELA targets should be viewed wit= h > > suspicion ..." And indeed the fields being non-zero causes section > > contents to be accumulated into the final relocated values in addit= ion to > > the relocations' addends, which is contrary to the ELF spec. > > Are you using NASM? > > -- > H.J. --=20 H.J.