From: Jan Beulich <jbeulich@suse.com>
To: "Kong, Lingling" <lingling.kong@intel.com>
Cc: "H. J. Lu" <hjl.tools@gmail.com>,
"binutils@sourceware.org" <binutils@sourceware.org>
Subject: Re: [PATCH v2] x86-64: Relax BFD_RELOC_X86_64_GOTTPOFF check
Date: Mon, 1 Jul 2024 10:08:42 +0200 [thread overview]
Message-ID: <3aae1f88-f15e-4a75-93a3-fec448512ea2@suse.com> (raw)
In-Reply-To: <DM4PR11MB5487037DE33BF9CC0B59E544ECD32@DM4PR11MB5487.namprd11.prod.outlook.com>
On 01.07.2024 09:21, Kong, Lingling wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Monday, July 1, 2024 2:15 PM
>> To: Kong, Lingling <lingling.kong@intel.com>
>> Cc: H. J. Lu <hjl.tools@gmail.com>; binutils@sourceware.org
>> Subject: Re: [PATCH v2] x86-64: Relax BFD_RELOC_X86_64_GOTTPOFF check
>>
>> On 01.07.2024 05:03, Kong, Lingling wrote:
>>> --- a/gas/config/tc-i386.c
>>> +++ b/gas/config/tc-i386.c
>>> @@ -7137,8 +7137,14 @@ md_assemble (char *line)
>>> && i.base_reg
>>> && i.base_reg->reg_num == RegIP
>>> && i.tm.operand_types[0].bitfield.class == Reg
>>> - && i.tm.operand_types[2].bitfield.class == Reg)
>>> - /* Allow APX: add %reg1, foo@gottpoff(%rip), %reg2. */
>>> + && (i.tm.operand_types[2].bitfield.class == Reg
>>> + || i.tm.operands == 2))
>>
>> As before: You allow more than what you claim in the comment below, unless I
>> continue to be overlooking something: Aiui you want to exclude forms with
>> memory destination.
>>
>>> + /* Allow APX:
>>> + add %reg1, foo@gottpoff(%rip), %reg2
>>> + add foo@gottpoff(%rip), %reg, %reg2
>>> + {nf} add foo@gottpoff(%rip), %reg
>>> + {nf} add %reg1, foo@gottpoff(%rip), %reg2
>>> + {nf} add foo@gottpoff(%rip), %reg, %reg2.
>>> + */
>>> break;
>>
>> I don't think the {nf} forms need naming specially. Or if they did, I wouldn't see -
>> as mentioned before - why the {evex} forms won't need/want mentioning, too.
>>
>> From the presentation below one can get the impression that you're altering
>> indentation of the comment. It was properly indented though.
>> However, your patch also pretty clearly came through with corrupted whitespace
>> (no hard tabs at all), so it's not really clear what changes.
>
> Sorry for my corrupted whitespace, there was a problem with the format of my email, so I re-sent the attachment. This version only modified the comment part, and the rest remained unchanged.
Thanks. Formatting there indeed looks okay.
> For such TLS sequences, it should only generated by compiler like GCC or LLVM not handwritten assembly codes.
Who or what says that hand-written assembly isn't permitted here? Who
or what says that compilers will only ever emit correct sequences? See
my earlier question to H.J. (which sadly has been left without actual
answer) - imo this either wants making as strict as possible or as
relaxed as possible. Anything in the middle is going to be entirely
arbitrary, and would hence need to come with a good explanation of why
exactly it is done like this.
Jan
prev parent reply other threads:[~2024-07-01 8:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-01 3:03 Kong, Lingling
2024-07-01 6:15 ` Jan Beulich
2024-07-01 7:21 ` Kong, Lingling
2024-07-01 8:08 ` Jan Beulich [this message]
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=3aae1f88-f15e-4a75-93a3-fec448512ea2@suse.com \
--to=jbeulich@suse.com \
--cc=binutils@sourceware.org \
--cc=hjl.tools@gmail.com \
--cc=lingling.kong@intel.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).