public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Fangrui Song <i@maskray.me>
To: Todor Buyukliev <tbuyukliev@vmware.com>
Cc: "binutils@sourceware.org" <binutils@sourceware.org>
Subject: Re: [PATCH] gas, x86: add -mno-plt32 option to disable PLT32 relocations
Date: Sun, 12 Dec 2021 21:17:20 -0800	[thread overview]
Message-ID: <20211213051720.ke4ztrjji7mmun6f@gmail.com> (raw)
In-Reply-To: <CO1PR05MB85535C178D8D51D2714312FDBD719@CO1PR05MB8553.namprd05.prod.outlook.com>

On 2021-12-10, Todor Buyukliev via Binutils wrote:
>hi, any interest in this?

This goes in the wrong direction.

Can you elaborate why your projects cannot handle R_X86_64_PLT32?
Using R_X86_64_PC32/R_386_PC32 is actually not good because it carries
strictly less information when the intention is to jump to the target.
See https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entries-and-protected
about canonical PLT entries.

>From: Todor Buyukliev <tbuyukliev@vmware.com>
>Date: Wednesday, 20 October 2021, 12:58
>To: binutils@sourceware.org <binutils@sourceware.org>
>Subject: [PATCH] gas, x86: add -mno-plt32 option to disable PLT32 relocations
>hi all,
>
>here’s a patch that we need. it’s against 2.34. can it be merged to master?
>
>regards,
>todor
>
>
>[PATCH] gas, x86: add -mno-plt32 option to disable PLT32 relocations
>
>---
>gas/ChangeLog        |  9 +++++++++
>gas/config/tc-i386.c | 15 +++++++++++++++
>2 files changed, 24 insertions(+)
>
>diff --git a/gas/ChangeLog b/gas/ChangeLog
>index ac92d076ef9..f70c8d45db9 100644
>--- a/gas/ChangeLog
>+++ b/gas/ChangeLog
>@@ -1,3 +1,12 @@
>+2021-05-28  Todor Buyukliev  <tbuyukliev@vmware.com>
>+
>+   * config/t-i386.c (disable_plt32): New declaration.
>+   (md_show_usage): Add -mno-plt32.
>+   (need_plt32_p): Return false if disable_plt32 is set.
>+   (OPTION_MNO_PLT32): New define.
>+   (md_longopts): Support mno-plt32 option.
>+   (md_parse_option): Likewise.
>+
>2020-02-10  H.J. Lu  <hongjiu.lu@intel.com>
>                PR gas/25516
>diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
>index 3f1d4cab7e5..1af97c0d149 100644
>--- a/gas/config/tc-i386.c
>+++ b/gas/config/tc-i386.c
>@@ -592,6 +592,9 @@ static int use_big_obj = 0;
>#if defined (OBJ_ELF) || defined (OBJ_MAYBE_ELF)
>/* 1 if generating code for a shared library.  */
>static int shared = 0;
>+
>+/* Non-zero to disable PLT32 relocations. */
>+static int disable_plt32 = 0;
>#endif
> /* 1 for intel syntax,
>@@ -7991,6 +7994,10 @@ need_plt32_p (symbolS *s)
>   return FALSE;
>#endif
>+  /* Don't emit PLT32 relocation if asked to.  */
>+  if (disable_plt32)
>+    return FALSE;
>+
>   /* Since there is no need to prepare for PLT branch on x86-64, we
>      can generate R_X86_64_PLT32, instead of R_X86_64_PC32, which can
>      be used as a marker for 32-bit PC-relative branches.  */
>@@ -12051,6 +12058,7 @@ const char *md_shortopts = "qnO::";
>#define OPTION_MALIGN_BRANCH_PREFIX_SIZE (OPTION_MD_BASE + 28)
>#define OPTION_MALIGN_BRANCH (OPTION_MD_BASE + 29)
>#define OPTION_MBRANCHES_WITH_32B_BOUNDARIES (OPTION_MD_BASE + 30)
>+#define OPTION_MNO_PLT32 (OPTION_MD_BASE + 31)
> struct option md_longopts[] =
>{
>@@ -12063,6 +12071,7 @@ struct option md_longopts[] =
>   {"x32", no_argument, NULL, OPTION_X32},
>   {"mshared", no_argument, NULL, OPTION_MSHARED},
>   {"mx86-used-note", required_argument, NULL, OPTION_X86_USED_NOTE},
>+  {"mno-plt32", no_argument, NULL, OPTION_MNO_PLT32},
>#endif
>   {"divide", no_argument, NULL, OPTION_DIVIDE},
>   {"march", required_argument, NULL, OPTION_MARCH},
>@@ -12193,6 +12202,10 @@ md_parse_option (int c, const char *arg)
>       else
>               as_fatal (_("32bit x86_64 is only supported for ELF"));
>       break;
>+
>+    case OPTION_MNO_PLT32:
>+      disable_plt32 = 1;
>+      break;
>#endif
>     case OPTION_32:
>@@ -12791,6 +12804,8 @@ md_show_usage (FILE *stream)
>     fprintf (stream, _("(default: no)\n"));
>   fprintf (stream, _("\
>                           generate x86 used ISA and feature properties\n"));
>+  fprintf (stream, _("\
>+  -mno-plt32              don't generate PLT32 relocations\n"));
>#endif
>#if defined (TE_PE) || defined (TE_PEP)
>   fprintf (stream, _("\
>--
>

  reply	other threads:[~2021-12-13  5:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-20  9:58 Todor Buyukliev
2021-12-10 15:16 ` Todor Buyukliev
2021-12-13  5:17   ` Fangrui Song [this message]
2021-12-10 15:29 ` H.J. Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211213051720.ke4ztrjji7mmun6f@gmail.com \
    --to=i@maskray.me \
    --cc=binutils@sourceware.org \
    --cc=tbuyukliev@vmware.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).