Message ID | 20240221145256.3118097-1-syq@gcc.gnu.org |
---|---|
State | Accepted |
Headers |
Return-Path: <binutils-bounces+ouuuleilei=gmail.com@sourceware.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2685:b0:108:e6aa:91d0 with SMTP id mn5csp1085048dyc; Wed, 21 Feb 2024 06:53:22 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXpNeHvEsMe1tGZP4k0CNx7OwjuXFn0qZpQyNjU1oXjH3XcWxVXYED2wJSu2NaWEDH/jKduxA7ph53G1mdt7TencruVFA== X-Google-Smtp-Source: AGHT+IGP47cidQCXNt51WgCKkFmVUt57C9+i7UrTUu3QLoV7MAOdQswLXFGb/EpAezK9LZDZpPwl X-Received: by 2002:a05:620a:4946:b0:784:71a6:f8df with SMTP id vz6-20020a05620a494600b0078471a6f8dfmr19509886qkn.44.1708527202481; Wed, 21 Feb 2024 06:53:22 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708527202; cv=pass; d=google.com; s=arc-20160816; b=AieuoO4qqa3H5atvKR0sRAKmV5bzO95scsRNNtJ5mKPAk/vEmTwZmUhtqBxxYAUzP3 qgIPm/7GIoaiReDbRh+kiYImHhN//yGoXmy+o4rvQxkoTH+u9oN3B60tctjnFidhLsV/ Gr9ElTYa3rG76T6w9AHwIbftZOknlulpyXrBuvjvlo+qJiZ2zAhar3eU25x6ovjkioHI KUiuj5SHydAA5XKWo0eUzW4VCAqb/Qtw2O5jY5Rr2wiXRqiFiZ9l+Lqtgn3Tico0YDt6 dQMY7COwH9Qou65noa+AE1xEB5O81NKQ1FBeeyeCkHh7x+Apadj4cnqFWaQJ4/1fbh6p U28Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:content-transfer-encoding :mime-version:message-id:date:subject:cc:to:from:arc-filter :dmarc-filter:delivered-to:dkim-signature:dkim-filter; bh=SkC89bR+p89gvGaM0JfPa3Tz0Gr4KhkxNDUewni9CFM=; fh=aLfIqSE0ZAz0y9OZZ7DbEg7tg8klNyv5+gEVfKCR14s=; b=b6t0MC7fVggyK7m66b96xXf/6PMso2QuJBgpNnJLZKycCBf20egXcrvebUtNaSsBEj Xa/aMz4aJYNzuFUcHtmcJGMKFKIoGj9gJ8p6TAFmSDEukpDJH61B+1Ms7uJvjwQu4TIl u1r7IuXtTyn8m54P15DgU71hr1PLHEaPZSHvkXqD9iWNiEQla9NkOtPYZQ2yzG3Zb9wI XXeGztCaIPfTi5qC5FRxW7mxoI7hBHKlic2lir1VGigNI25LgXePHB9zQlT4t+yblWgA Y+sGULxjErl+uJJmbTT3CBT8td5DjWtIAypFaJZ5mgoM52bwqpiFetfvXBs/OZ1HLfL7 099g==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b="jD84K/VS"; arc=pass (i=1); spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="binutils-bounces+ouuuleilei=gmail.com@sourceware.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (server2.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id l3-20020ae9f003000000b007871a99f99asi10505652qkg.782.2024.02.21.06.53.22 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Feb 2024 06:53:22 -0800 (PST) Received-SPF: pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b="jD84K/VS"; arc=pass (i=1); spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="binutils-bounces+ouuuleilei=gmail.com@sourceware.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0436B385840C for <ouuuleilei@gmail.com>; Wed, 21 Feb 2024 14:53:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0436B385840C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1708527202; bh=SkC89bR+p89gvGaM0JfPa3Tz0Gr4KhkxNDUewni9CFM=; h=From:To:Cc:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From; b=jD84K/VSInV3Th8BVtQciCKaRA0/xV5PYRzJ6Orry+6tVHnh/NQTmdw/QOjRmA90N TSaXD5nF0/f58KuN9nR/DjScT4YF8czV0StmAGDmN8g453QAXKVH4Co4/PX93V4dOh 275oKKMvQa80M7UcUemmE8WOTAJvFjNkd4Zo9OzY= X-Original-To: binutils@sourceware.org Delivered-To: binutils@sourceware.org Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by sourceware.org (Postfix) with ESMTPS id D1F5C3858C50 for <binutils@sourceware.org>; Wed, 21 Feb 2024 14:53:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D1F5C3858C50 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gcc.gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D1F5C3858C50 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.214.181 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708527190; cv=none; b=MN46VioRhMvJzLNXAYXpJ3XZhHf2alMyImUFoSoBiuyLHXeSZBBNsPVD66N/kLeaxbjTdi7djQl+TII5BVDbDeX7YftQvbymBjZMVeltNGdAhwAwRSbTqGrMDmTHcr2+INivtIt+Hpbg38aGvYS0wUObOltkZjiKfXCm1WftcX0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708527190; c=relaxed/simple; bh=ctDhq7oseQBx0DfIECPBzrvDWwnrufNqiKUxPzMGpJ0=; h=From:To:Subject:Date:Message-Id:MIME-Version; b=RgE3q6/+Qw4s0iRiUawTHrgp/g9JFVvq+MzLs9gEqWsSmc1kF76YluM8iFBKnxJqt/KFQCRWE0y4kQ/orTXpn9RM+6CBlt6e4mJSQEOJUWqs2pSTYaZcFsZPsmutF509+21Mm++UxyKuTNn6MWVAlWfAzO0tnLmqqOy0Wkp7gz8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-1db6e0996ceso49748705ad.2 for <binutils@sourceware.org>; Wed, 21 Feb 2024 06:53:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708527186; x=1709131986; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SkC89bR+p89gvGaM0JfPa3Tz0Gr4KhkxNDUewni9CFM=; b=XVt2Em/Z8GjbhSquZwHpLRj/q9MTPJDFJoyul+YdL0HHm8WP1ZseLuqQucy4gfRUQS Yem72+DxVgpF94tHPmzxjI/wdptczerLOLxhk3wcfo6vC4BvrULhK/DLpfCvaZgK8TmX HqeO2LgG2D2faag7iIGq6x+aCYCM/9nLPIUbZo2W8Kmzk+w0I0Pit+TT2Q295l8idnv9 ZDdS9FIaB6XiXeCEGpOtNQxdBTh5G9EBFpOWFLubVSLjlIHIzEX0wzw4zKqIeiS4Wl6S 0zS6rGUUyfogffmRPj2riZHYCyG8r/ulRCuV9YXZZbaa406ZXFOwb9F5lievC5tnFSZx J4BQ== X-Gm-Message-State: AOJu0Yxl17CIZxCrnzhutwU1wViChDPS6Byxr5m/ArNUFpTvalsMsTXd 9IybtmmCLnMafHr2hRw6u8K6ogpe0+sspStGYg8Egvora13D+Ziq X-Received: by 2002:a17:902:6b8b:b0:1db:670d:27d9 with SMTP id p11-20020a1709026b8b00b001db670d27d9mr13066619plk.27.1708527185614; Wed, 21 Feb 2024 06:53:05 -0800 (PST) Received: from localhost.localdomain ([149.248.38.156]) by smtp.gmail.com with ESMTPSA id r9-20020a170903014900b001da105d6a83sm8204127plc.224.2024.02.21.06.53.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Feb 2024 06:53:05 -0800 (PST) From: YunQiang Su <syq@gcc.gnu.org> To: nickc@redhat.com Cc: binutils@sourceware.org, macro@orcam.me.uk, xry111@xry111.site Subject: [PATCH v6] MIPS: Reject branch absolute relocs for PIC for linking Date: Wed, 21 Feb 2024 22:52:56 +0800 Message-Id: <20240221145256.3118097-1-syq@gcc.gnu.org> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.9 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, 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 X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Binutils mailing list <binutils.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/binutils>, <mailto:binutils-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/binutils/> List-Post: <mailto:binutils@sourceware.org> List-Help: <mailto:binutils-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/binutils>, <mailto:binutils-request@sourceware.org?subject=subscribe> Errors-To: binutils-bounces+ouuuleilei=gmail.com@sourceware.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791520619926184497 X-GMAIL-MSGID: 1791520619926184497 |
Series |
[v6] MIPS: Reject branch absolute relocs for PIC for linking
|
|
Checks
Context | Check | Description |
---|---|---|
snail/binutils-gdb-check | success | Github commit url |
Commit Message
YunQiang Su
Feb. 21, 2024, 2:52 p.m. UTC
The asm code like: b 8 will emit absolute relocs like: R_MIPS_PC16 *ABS* If they are included into PIC shared objects or PIE executables, the branch target will be like 0x12340000, which will make the programs crash. --- bfd/elfxx-mips.c | 9 +++++++++ ld/testsuite/ld-mips-elf/mips-elf.exp | 1 + ld/testsuite/ld-mips-elf/pic-reject-abs-reloc.d | 5 +++++ ld/testsuite/ld-mips-elf/pic-reject-abs-reloc.s | 2 ++ 4 files changed, 17 insertions(+) create mode 100644 ld/testsuite/ld-mips-elf/pic-reject-abs-reloc.d create mode 100644 ld/testsuite/ld-mips-elf/pic-reject-abs-reloc.s
Comments
A random comment: On Wed, 21 Feb 2024, YunQiang Su wrote: > The asm code like: > b 8 > will emit absolute relocs like: > R_MIPS_PC16 *ABS* > > If they are included into PIC shared objects or PIE executables, > the branch target will be like 0x12340000, which will make the > programs crash. > --- > bfd/elfxx-mips.c | 9 +++++++++ > ld/testsuite/ld-mips-elf/mips-elf.exp | 1 + > ld/testsuite/ld-mips-elf/pic-reject-abs-reloc.d | 5 +++++ > ld/testsuite/ld-mips-elf/pic-reject-abs-reloc.s | 2 ++ > 4 files changed, 17 insertions(+) > create mode 100644 ld/testsuite/ld-mips-elf/pic-reject-abs-reloc.d > create mode 100644 ld/testsuite/ld-mips-elf/pic-reject-abs-reloc.s > > diff --git a/bfd/elfxx-mips.c b/bfd/elfxx-mips.c > index 69dd71419ff..9542250dec4 100644 > --- a/bfd/elfxx-mips.c > +++ b/bfd/elfxx-mips.c > @@ -9258,6 +9258,15 @@ _bfd_mips_elf_check_relocs (bfd *abfd, struct bfd_link_info *info, > (h) ? h->root.root.string : "a local symbol"); > break; > default: > + if (branch_reloc_p (r_type) && r_symndx == STN_UNDEF) > + { > + howto = MIPS_ELF_RTYPE_TO_HOWTO (abfd, r_type, NEWABI_P (abfd)); > + info->callbacks->einfo > + /* xgettext:c-format */ > + (_("%X%H: relocation %s against `*ABS*' cannot be used" There's no "*ABS*" in the source and IMHO that'd look confusing to innocent users. How about "...against an absolute value"? Or "...against an absolute value or absolute symbol"? Perhaps the latter is a bit too wordy, but also more complete. > + " when making a PIC/PIE object\n"), > + abfd, sec, rel->r_offset, howto->name); > + } > break; brgds, H-P
> > + howto = MIPS_ELF_RTYPE_TO_HOWTO (abfd, r_type, NEWABI_P (abfd)); > > + info->callbacks->einfo > > + /* xgettext:c-format */ > > + (_("%X%H: relocation %s against `*ABS*' cannot be used" > > There's no "*ABS*" in the source and IMHO that'd look confusing > to innocent users. How about "...against an absolute value"? > Or "...against an absolute value or absolute symbol"? Perhaps > the latter is a bit too wordy, but also more complete. > Good idea. I think that we should use "...against an absolute value". "absolute symbol" is not included in this code, as it's r_symndx is not STN_UNDEF. An example is gas/testsuite/gas/mips/branch-absolute.s. Thank you,
On Thu, 22 Feb 2024, YunQiang Su wrote: > > > + howto = MIPS_ELF_RTYPE_TO_HOWTO (abfd, r_type, NEWABI_P (abfd)); > > > + info->callbacks->einfo > > > + /* xgettext:c-format */ > > > + (_("%X%H: relocation %s against `*ABS*' cannot be used" > > > > There's no "*ABS*" in the source and IMHO that'd look confusing > > to innocent users. How about "...against an absolute value"? > > Or "...against an absolute value or absolute symbol"? Perhaps > > the latter is a bit too wordy, but also more complete. > > > > Good idea. I think that we should use "...against an absolute value". > "absolute symbol" is not included in this code, as it's r_symndx is > not STN_UNDEF. Well code says otherwise: + if (branch_reloc_p (r_type) && r_symndx == STN_UNDEF) did you mean "the relocation's r_symndx is STN_UNDEF"? But it can be a relocation against an absolute symbol, for example if the symbol referred to by a relocation is supplied by another module in the link or a linker script and said symbol is absolute. This case has to be covered in testing as well, as I infer from your code it won't be handled correctly. In fact this situation is not unique to branch relocations, because no PC-relative relocation against an absolute symbol or value can be resolved at link time for PIC/PIE links. So you need to make your code generic for any relocations that have the `pc_relative' flag set in their howto unless we have a way to make a dynamic relocation out of such a relocation (which is none right now, as we still only have R_MIPS_REL32 as the sole dynamic relocation, except for TLS stuff). Extra test cases will be appreciated if you can come up with ones. Maciej
Maciej W. Rozycki <macro@orcam.me.uk> 于2024年2月22日周四 21:13写道: > > On Thu, 22 Feb 2024, YunQiang Su wrote: > > > > > + howto = MIPS_ELF_RTYPE_TO_HOWTO (abfd, r_type, NEWABI_P (abfd)); > > > > + info->callbacks->einfo > > > > + /* xgettext:c-format */ > > > > + (_("%X%H: relocation %s against `*ABS*' cannot be used" > > > > > > There's no "*ABS*" in the source and IMHO that'd look confusing > > > to innocent users. How about "...against an absolute value"? > > > Or "...against an absolute value or absolute symbol"? Perhaps > > > the latter is a bit too wordy, but also more complete. > > > > > > > Good idea. I think that we should use "...against an absolute value". > > "absolute symbol" is not included in this code, as it's r_symndx is > > not STN_UNDEF. > > Well code says otherwise: > > + if (branch_reloc_p (r_type) && r_symndx == STN_UNDEF) > > did you mean "the relocation's r_symndx is STN_UNDEF"? > > But it can be a relocation against an absolute symbol, for example if the > symbol referred to by a relocation is supplied by another module in the > link or a linker script and said symbol is absolute. This case has to be I have no idea whether we should emit this error for this case: If the symbol is set by a linker script, and is near enough with our instruction, the object should be ok for PIC? If not near enough, a "relocation truncated to fit" error will emit. > covered in testing as well, as I infer from your code it won't be handled > correctly. > > In fact this situation is not unique to branch relocations, because no > PC-relative relocation against an absolute symbol or value can be resolved > at link time for PIC/PIE links. So you need to make your code generic for > any relocations that have the `pc_relative' flag set in their howto unless > we have a way to make a dynamic relocation out of such a relocation (which > is none right now, as we still only have R_MIPS_REL32 as the sole dynamic > relocation, except for TLS stuff). > > Extra test cases will be appreciated if you can come up with ones. > > Maciej
On Sun, 25 Feb 2024, YunQiang Su wrote: > > > Good idea. I think that we should use "...against an absolute value". > > > "absolute symbol" is not included in this code, as it's r_symndx is > > > not STN_UNDEF. > > > > Well code says otherwise: > > > > + if (branch_reloc_p (r_type) && r_symndx == STN_UNDEF) > > > > did you mean "the relocation's r_symndx is STN_UNDEF"? > > > > But it can be a relocation against an absolute symbol, for example if the > > symbol referred to by a relocation is supplied by another module in the > > link or a linker script and said symbol is absolute. This case has to be > > I have no idea whether we should emit this error for this case: > If the symbol is set by a linker script, and is near enough with > our instruction, > the object should be ok for PIC? > If not near enough, a "relocation truncated to fit" error will emit. If the symbol referred is absolute, then the case is no different from an absolute relocation. You just can't calculate a PC-relative reference to an absolute value at static link time, because the distance from PC to that value will depend on the base address at load time. It is different from a reference to a regular (non-absolute) symbol that just turns out too distant for a PC-relative relocation to reach (where the "relocation truncated to fit" case applies). Maciej
diff --git a/bfd/elfxx-mips.c b/bfd/elfxx-mips.c index 69dd71419ff..9542250dec4 100644 --- a/bfd/elfxx-mips.c +++ b/bfd/elfxx-mips.c @@ -9258,6 +9258,15 @@ _bfd_mips_elf_check_relocs (bfd *abfd, struct bfd_link_info *info, (h) ? h->root.root.string : "a local symbol"); break; default: + if (branch_reloc_p (r_type) && r_symndx == STN_UNDEF) + { + howto = MIPS_ELF_RTYPE_TO_HOWTO (abfd, r_type, NEWABI_P (abfd)); + info->callbacks->einfo + /* xgettext:c-format */ + (_("%X%H: relocation %s against `*ABS*' cannot be used" + " when making a PIC/PIE object\n"), + abfd, sec, rel->r_offset, howto->name); + } break; } } diff --git a/ld/testsuite/ld-mips-elf/mips-elf.exp b/ld/testsuite/ld-mips-elf/mips-elf.exp index 50af78d1430..a8e1b91b3a1 100644 --- a/ld/testsuite/ld-mips-elf/mips-elf.exp +++ b/ld/testsuite/ld-mips-elf/mips-elf.exp @@ -1678,6 +1678,7 @@ run_dump_test_o32 "pic-reloc-6" run_dump_test_n64 "pic-reloc-7" run_dump_test_n64 "pic-reloc-7" [list [list name (microMIPS)] \ [list as "-mmicromips"]] +run_dump_test "pic-reject-abs-reloc" run_dump_test_o32 "reloc-pcrel-r6" diff --git a/ld/testsuite/ld-mips-elf/pic-reject-abs-reloc.d b/ld/testsuite/ld-mips-elf/pic-reject-abs-reloc.d new file mode 100644 index 00000000000..16d9f4e8553 --- /dev/null +++ b/ld/testsuite/ld-mips-elf/pic-reject-abs-reloc.d @@ -0,0 +1,5 @@ +#name: MIPS PIC rejects branch absolute +#ld: -shared -T pic-reloc-absolute-lo.ld +#target: [check_shared_lib_support] +#error: \A[^\n]*: in function `foo':\n +#error: \(\.text\+0x0\): relocation R_MIPS_PC16 against `\*ABS\*' cannot be used when making a PIC/PIE object diff --git a/ld/testsuite/ld-mips-elf/pic-reject-abs-reloc.s b/ld/testsuite/ld-mips-elf/pic-reject-abs-reloc.s new file mode 100644 index 00000000000..a845fd50a77 --- /dev/null +++ b/ld/testsuite/ld-mips-elf/pic-reject-abs-reloc.s @@ -0,0 +1,2 @@ +foo: + b 8