* [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry
@ 2024-01-09 1:12 Indu Bhagat
2024-01-09 1:12 ` [PATCH] opcodes: gas: i386: use Rex2 as attribute not constraint Indu Bhagat
2024-01-09 8:24 ` [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry Jan Beulich
0 siblings, 2 replies; 12+ messages in thread
From: Indu Bhagat @ 2024-01-09 1:12 UTC (permalink / raw)
To: binutils; +Cc: Indu Bhagat
The DWARF register numbers for the APX EGRPs start with 130. The data
type holding the same currently is signed char.
ChangeLog:
* opcodes/i386-opc.h (reg_entry): Bump to signed short.
---
opcodes/i386-opc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
index 61a11214914..38661ffe70c 100644
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -1047,7 +1047,7 @@ typedef struct
#define RegIZ (RegIP - 1)
/* FLAT is a fake segment register (Intel mode). */
#define RegFlat ((unsigned char) ~0)
- signed char dw2_regnum[2];
+ signed short dw2_regnum[2];
#define Dw2Inval (-1)
}
reg_entry;
--
2.41.0
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] opcodes: gas: i386: use Rex2 as attribute not constraint
2024-01-09 1:12 [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry Indu Bhagat
@ 2024-01-09 1:12 ` Indu Bhagat
2024-01-09 8:14 ` Jan Beulich
2024-01-09 8:24 ` [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry Jan Beulich
1 sibling, 1 reply; 12+ messages in thread
From: Indu Bhagat @ 2024-01-09 1:12 UTC (permalink / raw)
To: binutils; +Cc: Indu Bhagat
It seems to fit better if Rex2 is an attribute for now rather than a
constraint.
PS: Removed the opcodes/i386-tbl.h diffs from patch to keep the message
size within limits.
ChangeLog:
* gas/config/tc-i386.c (is_apx_rex2_encoding): Update the check.
* opcodes/i386-gen.c: Add a new BITFIELD for Rex2.
* opcodes/i386-opc.h (REX2_REQUIRED): Remove.
* opcodes/i386-opc.tbl: Remove Rex2 operand constraint.
* opcodes/i386-tbl.h: Regenerated.
---
gas/config/tc-i386.c | 2 +-
opcodes/i386-gen.c | 1 +
opcodes/i386-opc.h | 6 +-
opcodes/i386-opc.tbl | 1 -
opcodes/i386-tbl.h | 11659 +++++++++++++++++++++++++++--------------
5 files changed, 7778 insertions(+), 3891 deletions(-)
diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index 27d0742c6c8..b25cc517240 100644
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -3929,7 +3929,7 @@ static INLINE bool
is_apx_rex2_encoding (void)
{
return i.rex2 || i.rex2_encoding
- || i.tm.opcode_modifier.operandconstraint == REX2_REQUIRED;
+ || i.tm.opcode_modifier.rex2;
}
static unsigned int
diff --git a/opcodes/i386-gen.c b/opcodes/i386-gen.c
index e8b92e32f45..21331216486 100644
--- a/opcodes/i386-gen.c
+++ b/opcodes/i386-gen.c
@@ -490,6 +490,7 @@ static bitfield opcode_modifiers[] =
BITFIELD (ISA64),
BITFIELD (NoEgpr),
BITFIELD (NF),
+ BITFIELD (Rex2),
};
#define CLASS(n) #n, n
diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
index 38661ffe70c..eaebfaa9ba8 100644
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -579,8 +579,6 @@ enum
/* Instrucion requires that destination must be distinct from source
registers. */
#define DISTINCT_DEST 9
- /* Instrucion requires REX2 prefix. */
-#define REX2_REQUIRED 10
OperandConstraint,
/* instruction ignores operand size prefix and in Intel mode ignores
mnemonic size suffix check. */
@@ -750,6 +748,9 @@ enum
/* No CSPAZO flags update indication. */
NF,
+ /* Instrucion requires REX2 prefix. */
+ Rex2,
+
/* The last bitfield in i386_opcode_modifier. */
Opcode_Modifier_Num
};
@@ -796,6 +797,7 @@ typedef struct i386_opcode_modifier
unsigned int isa64:2;
unsigned int noegpr:1;
unsigned int nf:1;
+ unsigned int rex2:1;
} i386_opcode_modifier;
/* Operand classes. */
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index 1751eff8bd2..ada5c06e501 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -85,7 +85,6 @@
#define RegKludge OperandConstraint=REG_KLUDGE
#define SwapSources OperandConstraint=SWAP_SOURCES
#define Ugh OperandConstraint=UGH
-#define Rex2 OperandConstraint=REX2_REQUIRED
#define ATTSyntax Dialect=ATT_SYNTAX
#define ATTMnemonic Dialect=ATT_MNEMONIC
--
2.41.0
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] opcodes: gas: i386: use Rex2 as attribute not constraint
2024-01-09 1:12 ` [PATCH] opcodes: gas: i386: use Rex2 as attribute not constraint Indu Bhagat
@ 2024-01-09 8:14 ` Jan Beulich
0 siblings, 0 replies; 12+ messages in thread
From: Jan Beulich @ 2024-01-09 8:14 UTC (permalink / raw)
To: Indu Bhagat; +Cc: binutils
On 09.01.2024 02:12, Indu Bhagat wrote:
> It seems to fit better if Rex2 is an attribute for now rather than a
> constraint.
On its own, I disagree with this as justification. When it was introduced,
I had specifically asked for it to be the way it is right now. The issue
with it is that it conflicts with an operand constraint you mean to add.
So while I'm okay with the code change, I'd like to ask that
- the description be extended,
- the patch be part of the SCFI series, preferably to also be committed
together with the (subsequent) patch introducing the new operand
constraint.
Jan
> PS: Removed the opcodes/i386-tbl.h diffs from patch to keep the message
> size within limits.
>
> ChangeLog:
> * gas/config/tc-i386.c (is_apx_rex2_encoding): Update the check.
> * opcodes/i386-gen.c: Add a new BITFIELD for Rex2.
> * opcodes/i386-opc.h (REX2_REQUIRED): Remove.
> * opcodes/i386-opc.tbl: Remove Rex2 operand constraint.
> * opcodes/i386-tbl.h: Regenerated.
> ---
> gas/config/tc-i386.c | 2 +-
> opcodes/i386-gen.c | 1 +
> opcodes/i386-opc.h | 6 +-
> opcodes/i386-opc.tbl | 1 -
> opcodes/i386-tbl.h | 11659 +++++++++++++++++++++++++++--------------
> 5 files changed, 7778 insertions(+), 3891 deletions(-)
>
> diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
> index 27d0742c6c8..b25cc517240 100644
> --- a/gas/config/tc-i386.c
> +++ b/gas/config/tc-i386.c
> @@ -3929,7 +3929,7 @@ static INLINE bool
> is_apx_rex2_encoding (void)
> {
> return i.rex2 || i.rex2_encoding
> - || i.tm.opcode_modifier.operandconstraint == REX2_REQUIRED;
> + || i.tm.opcode_modifier.rex2;
> }
>
> static unsigned int
> diff --git a/opcodes/i386-gen.c b/opcodes/i386-gen.c
> index e8b92e32f45..21331216486 100644
> --- a/opcodes/i386-gen.c
> +++ b/opcodes/i386-gen.c
> @@ -490,6 +490,7 @@ static bitfield opcode_modifiers[] =
> BITFIELD (ISA64),
> BITFIELD (NoEgpr),
> BITFIELD (NF),
> + BITFIELD (Rex2),
> };
>
> #define CLASS(n) #n, n
> diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
> index 38661ffe70c..eaebfaa9ba8 100644
> --- a/opcodes/i386-opc.h
> +++ b/opcodes/i386-opc.h
> @@ -579,8 +579,6 @@ enum
> /* Instrucion requires that destination must be distinct from source
> registers. */
> #define DISTINCT_DEST 9
> - /* Instrucion requires REX2 prefix. */
> -#define REX2_REQUIRED 10
> OperandConstraint,
> /* instruction ignores operand size prefix and in Intel mode ignores
> mnemonic size suffix check. */
> @@ -750,6 +748,9 @@ enum
> /* No CSPAZO flags update indication. */
> NF,
>
> + /* Instrucion requires REX2 prefix. */
> + Rex2,
> +
> /* The last bitfield in i386_opcode_modifier. */
> Opcode_Modifier_Num
> };
> @@ -796,6 +797,7 @@ typedef struct i386_opcode_modifier
> unsigned int isa64:2;
> unsigned int noegpr:1;
> unsigned int nf:1;
> + unsigned int rex2:1;
> } i386_opcode_modifier;
>
> /* Operand classes. */
> diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
> index 1751eff8bd2..ada5c06e501 100644
> --- a/opcodes/i386-opc.tbl
> +++ b/opcodes/i386-opc.tbl
> @@ -85,7 +85,6 @@
> #define RegKludge OperandConstraint=REG_KLUDGE
> #define SwapSources OperandConstraint=SWAP_SOURCES
> #define Ugh OperandConstraint=UGH
> -#define Rex2 OperandConstraint=REX2_REQUIRED
>
> #define ATTSyntax Dialect=ATT_SYNTAX
> #define ATTMnemonic Dialect=ATT_MNEMONIC
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry
2024-01-09 1:12 [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry Indu Bhagat
2024-01-09 1:12 ` [PATCH] opcodes: gas: i386: use Rex2 as attribute not constraint Indu Bhagat
@ 2024-01-09 8:24 ` Jan Beulich
2024-01-11 1:35 ` Kong, Lingling
1 sibling, 1 reply; 12+ messages in thread
From: Jan Beulich @ 2024-01-09 8:24 UTC (permalink / raw)
To: Indu Bhagat, Lili Cui, H.J. Lu, Kong Lingling, Hu, Lin1; +Cc: binutils
On 09.01.2024 02:12, Indu Bhagat wrote:
> The DWARF register numbers for the APX EGRPs start with 130. The data
> type holding the same currently is signed char.
>
> ChangeLog:
> * opcodes/i386-opc.h (reg_entry): Bump to signed short.
So yes, something needs doing. But there are further questions to be
raised to the original authors: Was the code tested at all in this
regard? Why do numbers start at 130, when according to i386-reg.tbl
128 and 129 are unused (and would hence be more natural to [also]
use)?
> --- a/opcodes/i386-opc.h
> +++ b/opcodes/i386-opc.h
> @@ -1047,7 +1047,7 @@ typedef struct
> #define RegIZ (RegIP - 1)
> /* FLAT is a fake segment register (Intel mode). */
> #define RegFlat ((unsigned char) ~0)
> - signed char dw2_regnum[2];
> + signed short dw2_regnum[2];
> #define Dw2Inval (-1)
> }
> reg_entry;
It's a little sad that non-64-bit field also has its size increased.
Right now either way the structure size as a whole is the same, but
down the road this may end up a little wasteful.
Jan
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry
2024-01-09 8:24 ` [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry Jan Beulich
@ 2024-01-11 1:35 ` Kong, Lingling
2024-01-11 7:43 ` Jan Beulich
0 siblings, 1 reply; 12+ messages in thread
From: Kong, Lingling @ 2024-01-11 1:35 UTC (permalink / raw)
To: Beulich, Jan, Indu Bhagat, Cui, Lili, H.J. Lu, Hu, Lin1; +Cc: binutils
> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Tuesday, January 9, 2024 4:25 PM
> To: Indu Bhagat <indu.bhagat@oracle.com>; Cui, Lili <lili.cui@intel.com>; H.J. Lu
> <hjl.tools@gmail.com>; Kong, Lingling <lingling.kong@intel.com>; Hu, Lin1
> <lin1.hu@intel.com>
> Cc: binutils@sourceware.org
> Subject: Re: [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry
>
> On 09.01.2024 02:12, Indu Bhagat wrote:
> > The DWARF register numbers for the APX EGRPs start with 130. The data
> > type holding the same currently is signed char.
> >
> > ChangeLog:
> > * opcodes/i386-opc.h (reg_entry): Bump to signed short.
>
> So yes, something needs doing. But there are further questions to be raised to the
> original authors: Was the code tested at all in this regard? Why do numbers start
> at 130, when according to i386-reg.tbl
> 128 and 129 are unused (and would hence be more natural to [also] use)?
>
Hi,
This is because for some historical reasons, some numbers(126-129) have been agreed to be reserved.
Details can be found in https://groups.google.com/g/x86-64-abi/c/GS8LZf5nQFk.
Thanks!
Lingling
-> > --- a/opcodes/i386-opc.h
> > +++ b/opcodes/i386-opc.h
> > @@ -1047,7 +1047,7 @@ typedef struct
> > #define RegIZ (RegIP - 1)
> > /* FLAT is a fake segment register (Intel mode). */
> > #define RegFlat ((unsigned char) ~0)
> > - signed char dw2_regnum[2];
> > + signed short dw2_regnum[2];
> > #define Dw2Inval (-1)
> > }
> > reg_entry;
>
> It's a little sad that non-64-bit field also has its size increased.
> Right now either way the structure size as a whole is the same, but down the
> road this may end up a little wasteful.
>
> Jan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry
2024-01-11 1:35 ` Kong, Lingling
@ 2024-01-11 7:43 ` Jan Beulich
2024-01-11 7:59 ` Kong, Lingling
0 siblings, 1 reply; 12+ messages in thread
From: Jan Beulich @ 2024-01-11 7:43 UTC (permalink / raw)
To: Kong, Lingling; +Cc: binutils, Indu Bhagat, Cui, Lili, H.J. Lu, Hu, Lin1
On 11.01.2024 02:35, Kong, Lingling wrote:
>
>
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Tuesday, January 9, 2024 4:25 PM
>> To: Indu Bhagat <indu.bhagat@oracle.com>; Cui, Lili <lili.cui@intel.com>; H.J. Lu
>> <hjl.tools@gmail.com>; Kong, Lingling <lingling.kong@intel.com>; Hu, Lin1
>> <lin1.hu@intel.com>
>> Cc: binutils@sourceware.org
>> Subject: Re: [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry
>>
>> On 09.01.2024 02:12, Indu Bhagat wrote:
>>> The DWARF register numbers for the APX EGRPs start with 130. The data
>>> type holding the same currently is signed char.
>>>
>>> ChangeLog:
>>> * opcodes/i386-opc.h (reg_entry): Bump to signed short.
>>
>> So yes, something needs doing. But there are further questions to be raised to the
>> original authors: Was the code tested at all in this regard? Why do numbers start
>> at 130, when according to i386-reg.tbl
>> 128 and 129 are unused (and would hence be more natural to [also] use)?
>
> This is because for some historical reasons, some numbers(126-129) have been agreed to be reserved.
> Details can be found in https://groups.google.com/g/x86-64-abi/c/GS8LZf5nQFk.
I'm sorry, there are no details there. There's merely mention of these four
being reserved, without supplying any reason (historical or not).
Jan
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry
2024-01-11 7:43 ` Jan Beulich
@ 2024-01-11 7:59 ` Kong, Lingling
2024-01-11 8:05 ` Jan Beulich
0 siblings, 1 reply; 12+ messages in thread
From: Kong, Lingling @ 2024-01-11 7:59 UTC (permalink / raw)
To: Beulich, Jan; +Cc: binutils, Indu Bhagat, Cui, Lili, H.J. Lu, Hu, Lin1
> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Thursday, January 11, 2024 3:43 PM
> To: Kong, Lingling <lingling.kong@intel.com>
> Cc: binutils@sourceware.org; Indu Bhagat <indu.bhagat@oracle.com>; Cui, Lili
> <lili.cui@intel.com>; H.J. Lu <hjl.tools@gmail.com>; Hu, Lin1
> <lin1.hu@intel.com>
> Subject: Re: [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry
>
> On 11.01.2024 02:35, Kong, Lingling wrote:
> >
> >
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Tuesday, January 9, 2024 4:25 PM
> >> To: Indu Bhagat <indu.bhagat@oracle.com>; Cui, Lili
> >> <lili.cui@intel.com>; H.J. Lu <hjl.tools@gmail.com>; Kong, Lingling
> >> <lingling.kong@intel.com>; Hu, Lin1 <lin1.hu@intel.com>
> >> Cc: binutils@sourceware.org
> >> Subject: Re: [PATCH] opcodes: i386: fix dw2_regnum data type in
> >> reg_entry
> >>
> >> On 09.01.2024 02:12, Indu Bhagat wrote:
> >>> The DWARF register numbers for the APX EGRPs start with 130. The
> >>> data type holding the same currently is signed char.
> >>>
> >>> ChangeLog:
> >>> * opcodes/i386-opc.h (reg_entry): Bump to signed short.
> >>
> >> So yes, something needs doing. But there are further questions to be
> >> raised to the original authors: Was the code tested at all in this
> >> regard? Why do numbers start at 130, when according to i386-reg.tbl
> >> 128 and 129 are unused (and would hence be more natural to [also] use)?
> >
> > This is because for some historical reasons, some numbers(126-129) have been
> agreed to be reserved.
> > Details can be found in https://groups.google.com/g/x86-64-
> abi/c/GS8LZf5nQFk.
>
> I'm sorry, there are no details there. There's merely mention of these four being
> reserved, without supplying any reason (historical or not).
>
> Jan
Sorry, you could see https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/6207f9a2c0645f20a7ec591a09e4c382b1675784
There are reserved for Intel MPX (Memory Protection Extensions) provides 4 128-bit wide bound registers (reg{bnd0} - reg{bnd3}).
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry
2024-01-11 7:59 ` Kong, Lingling
@ 2024-01-11 8:05 ` Jan Beulich
2024-01-11 13:27 ` H.J. Lu
0 siblings, 1 reply; 12+ messages in thread
From: Jan Beulich @ 2024-01-11 8:05 UTC (permalink / raw)
To: Kong, Lingling, H.J. Lu; +Cc: binutils, Indu Bhagat, Cui, Lili, Hu, Lin1
On 11.01.2024 08:59, Kong, Lingling wrote:
>
>
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Thursday, January 11, 2024 3:43 PM
>> To: Kong, Lingling <lingling.kong@intel.com>
>> Cc: binutils@sourceware.org; Indu Bhagat <indu.bhagat@oracle.com>; Cui, Lili
>> <lili.cui@intel.com>; H.J. Lu <hjl.tools@gmail.com>; Hu, Lin1
>> <lin1.hu@intel.com>
>> Subject: Re: [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry
>>
>> On 11.01.2024 02:35, Kong, Lingling wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: Tuesday, January 9, 2024 4:25 PM
>>>> To: Indu Bhagat <indu.bhagat@oracle.com>; Cui, Lili
>>>> <lili.cui@intel.com>; H.J. Lu <hjl.tools@gmail.com>; Kong, Lingling
>>>> <lingling.kong@intel.com>; Hu, Lin1 <lin1.hu@intel.com>
>>>> Cc: binutils@sourceware.org
>>>> Subject: Re: [PATCH] opcodes: i386: fix dw2_regnum data type in
>>>> reg_entry
>>>>
>>>> On 09.01.2024 02:12, Indu Bhagat wrote:
>>>>> The DWARF register numbers for the APX EGRPs start with 130. The
>>>>> data type holding the same currently is signed char.
>>>>>
>>>>> ChangeLog:
>>>>> * opcodes/i386-opc.h (reg_entry): Bump to signed short.
>>>>
>>>> So yes, something needs doing. But there are further questions to be
>>>> raised to the original authors: Was the code tested at all in this
>>>> regard? Why do numbers start at 130, when according to i386-reg.tbl
>>>> 128 and 129 are unused (and would hence be more natural to [also] use)?
>>>
>>> This is because for some historical reasons, some numbers(126-129) have been
>> agreed to be reserved.
>>> Details can be found in https://groups.google.com/g/x86-64-
>> abi/c/GS8LZf5nQFk.
>>
>> I'm sorry, there are no details there. There's merely mention of these four being
>> reserved, without supplying any reason (historical or not).
>
> Sorry, you could see https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/6207f9a2c0645f20a7ec591a09e4c382b1675784
> There are reserved for Intel MPX (Memory Protection Extensions) provides 4 128-bit wide bound registers (reg{bnd0} - reg{bnd3}).
Then why aren't these marked that way? The commit introducing them to
opcodes used Dw2Inval, and it was never changed from that (i.e. there
wasn't even deliberate undoing with respective justification).
Jan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry
2024-01-11 8:05 ` Jan Beulich
@ 2024-01-11 13:27 ` H.J. Lu
2024-01-11 14:05 ` Jan Beulich
0 siblings, 1 reply; 12+ messages in thread
From: H.J. Lu @ 2024-01-11 13:27 UTC (permalink / raw)
To: Jan Beulich; +Cc: Kong, Lingling, binutils, Indu Bhagat, Cui, Lili, Hu, Lin1
On Thu, Jan 11, 2024 at 12:05 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 11.01.2024 08:59, Kong, Lingling wrote:
> >
> >
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Thursday, January 11, 2024 3:43 PM
> >> To: Kong, Lingling <lingling.kong@intel.com>
> >> Cc: binutils@sourceware.org; Indu Bhagat <indu.bhagat@oracle.com>; Cui, Lili
> >> <lili.cui@intel.com>; H.J. Lu <hjl.tools@gmail.com>; Hu, Lin1
> >> <lin1.hu@intel.com>
> >> Subject: Re: [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry
> >>
> >> On 11.01.2024 02:35, Kong, Lingling wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Jan Beulich <jbeulich@suse.com>
> >>>> Sent: Tuesday, January 9, 2024 4:25 PM
> >>>> To: Indu Bhagat <indu.bhagat@oracle.com>; Cui, Lili
> >>>> <lili.cui@intel.com>; H.J. Lu <hjl.tools@gmail.com>; Kong, Lingling
> >>>> <lingling.kong@intel.com>; Hu, Lin1 <lin1.hu@intel.com>
> >>>> Cc: binutils@sourceware.org
> >>>> Subject: Re: [PATCH] opcodes: i386: fix dw2_regnum data type in
> >>>> reg_entry
> >>>>
> >>>> On 09.01.2024 02:12, Indu Bhagat wrote:
> >>>>> The DWARF register numbers for the APX EGRPs start with 130. The
> >>>>> data type holding the same currently is signed char.
> >>>>>
> >>>>> ChangeLog:
> >>>>> * opcodes/i386-opc.h (reg_entry): Bump to signed short.
> >>>>
> >>>> So yes, something needs doing. But there are further questions to be
> >>>> raised to the original authors: Was the code tested at all in this
> >>>> regard? Why do numbers start at 130, when according to i386-reg.tbl
> >>>> 128 and 129 are unused (and would hence be more natural to [also] use)?
> >>>
> >>> This is because for some historical reasons, some numbers(126-129) have been
> >> agreed to be reserved.
> >>> Details can be found in https://groups.google.com/g/x86-64-
> >> abi/c/GS8LZf5nQFk.
> >>
> >> I'm sorry, there are no details there. There's merely mention of these four being
> >> reserved, without supplying any reason (historical or not).
> >
> > Sorry, you could see https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/6207f9a2c0645f20a7ec591a09e4c382b1675784
> > There are reserved for Intel MPX (Memory Protection Extensions) provides 4 128-bit wide bound registers (reg{bnd0} - reg{bnd3}).
>
> Then why aren't these marked that way? The commit introducing them to
> opcodes used Dw2Inval, and it was never changed from that (i.e. there
> wasn't even deliberate undoing with respective justification).
>
Leave them as reserved. We have plenty.
--
H.J.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry
2024-01-11 13:27 ` H.J. Lu
@ 2024-01-11 14:05 ` Jan Beulich
2024-01-20 0:45 ` Indu Bhagat
0 siblings, 1 reply; 12+ messages in thread
From: Jan Beulich @ 2024-01-11 14:05 UTC (permalink / raw)
To: H.J. Lu; +Cc: Kong, Lingling, binutils, Indu Bhagat, Cui, Lili, Hu, Lin1
On 11.01.2024 14:27, H.J. Lu wrote:
> On Thu, Jan 11, 2024 at 12:05 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 11.01.2024 08:59, Kong, Lingling wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: Thursday, January 11, 2024 3:43 PM
>>>> To: Kong, Lingling <lingling.kong@intel.com>
>>>> Cc: binutils@sourceware.org; Indu Bhagat <indu.bhagat@oracle.com>; Cui, Lili
>>>> <lili.cui@intel.com>; H.J. Lu <hjl.tools@gmail.com>; Hu, Lin1
>>>> <lin1.hu@intel.com>
>>>> Subject: Re: [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry
>>>>
>>>> On 11.01.2024 02:35, Kong, Lingling wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>>> Sent: Tuesday, January 9, 2024 4:25 PM
>>>>>> To: Indu Bhagat <indu.bhagat@oracle.com>; Cui, Lili
>>>>>> <lili.cui@intel.com>; H.J. Lu <hjl.tools@gmail.com>; Kong, Lingling
>>>>>> <lingling.kong@intel.com>; Hu, Lin1 <lin1.hu@intel.com>
>>>>>> Cc: binutils@sourceware.org
>>>>>> Subject: Re: [PATCH] opcodes: i386: fix dw2_regnum data type in
>>>>>> reg_entry
>>>>>>
>>>>>> On 09.01.2024 02:12, Indu Bhagat wrote:
>>>>>>> The DWARF register numbers for the APX EGRPs start with 130. The
>>>>>>> data type holding the same currently is signed char.
>>>>>>>
>>>>>>> ChangeLog:
>>>>>>> * opcodes/i386-opc.h (reg_entry): Bump to signed short.
>>>>>>
>>>>>> So yes, something needs doing. But there are further questions to be
>>>>>> raised to the original authors: Was the code tested at all in this
>>>>>> regard? Why do numbers start at 130, when according to i386-reg.tbl
>>>>>> 128 and 129 are unused (and would hence be more natural to [also] use)?
>>>>>
>>>>> This is because for some historical reasons, some numbers(126-129) have been
>>>> agreed to be reserved.
>>>>> Details can be found in https://groups.google.com/g/x86-64-
>>>> abi/c/GS8LZf5nQFk.
>>>>
>>>> I'm sorry, there are no details there. There's merely mention of these four being
>>>> reserved, without supplying any reason (historical or not).
>>>
>>> Sorry, you could see https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/6207f9a2c0645f20a7ec591a09e4c382b1675784
>>> There are reserved for Intel MPX (Memory Protection Extensions) provides 4 128-bit wide bound registers (reg{bnd0} - reg{bnd3}).
>>
>> Then why aren't these marked that way? The commit introducing them to
>> opcodes used Dw2Inval, and it was never changed from that (i.e. there
>> wasn't even deliberate undoing with respective justification).
>
> Leave them as reserved. We have plenty.
Hmm, the latter sentence doesn't fir what I meant: Why does / did
i386-reg.tbl not / never have those numbers? I could have seen that
they were there and then possibly have been purged, but even then
I would expect there a comment to have been left. So minimally what
I'd like to see / do is to add such comments.
Jan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry
2024-01-11 14:05 ` Jan Beulich
@ 2024-01-20 0:45 ` Indu Bhagat
2024-01-22 7:49 ` Jan Beulich
0 siblings, 1 reply; 12+ messages in thread
From: Indu Bhagat @ 2024-01-20 0:45 UTC (permalink / raw)
To: Jan Beulich, H.J. Lu; +Cc: Kong, Lingling, binutils, Cui, Lili, Hu, Lin1
On 1/11/24 06:05, Jan Beulich wrote:
> On 11.01.2024 14:27, H.J. Lu wrote:
>> On Thu, Jan 11, 2024 at 12:05 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>
>>> On 11.01.2024 08:59, Kong, Lingling wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>> Sent: Thursday, January 11, 2024 3:43 PM
>>>>> To: Kong, Lingling <lingling.kong@intel.com>
>>>>> Cc: binutils@sourceware.org; Indu Bhagat <indu.bhagat@oracle.com>; Cui, Lili
>>>>> <lili.cui@intel.com>; H.J. Lu <hjl.tools@gmail.com>; Hu, Lin1
>>>>> <lin1.hu@intel.com>
>>>>> Subject: Re: [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry
>>>>>
>>>>> On 11.01.2024 02:35, Kong, Lingling wrote:
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>>>> Sent: Tuesday, January 9, 2024 4:25 PM
>>>>>>> To: Indu Bhagat <indu.bhagat@oracle.com>; Cui, Lili
>>>>>>> <lili.cui@intel.com>; H.J. Lu <hjl.tools@gmail.com>; Kong, Lingling
>>>>>>> <lingling.kong@intel.com>; Hu, Lin1 <lin1.hu@intel.com>
>>>>>>> Cc: binutils@sourceware.org
>>>>>>> Subject: Re: [PATCH] opcodes: i386: fix dw2_regnum data type in
>>>>>>> reg_entry
>>>>>>>
>>>>>>> On 09.01.2024 02:12, Indu Bhagat wrote:
>>>>>>>> The DWARF register numbers for the APX EGRPs start with 130. The
>>>>>>>> data type holding the same currently is signed char.
>>>>>>>>
>>>>>>>> ChangeLog:
>>>>>>>> * opcodes/i386-opc.h (reg_entry): Bump to signed short.
>>>>>>>
>>>>>>> So yes, something needs doing. But there are further questions to be
>>>>>>> raised to the original authors: Was the code tested at all in this
>>>>>>> regard? Why do numbers start at 130, when according to i386-reg.tbl
>>>>>>> 128 and 129 are unused (and would hence be more natural to [also] use)?
>>>>>>
>>>>>> This is because for some historical reasons, some numbers(126-129) have been
>>>>> agreed to be reserved.
>>>>>> Details can be found in https://groups.google.com/g/x86-64-
>>>>> abi/c/GS8LZf5nQFk.
>>>>>
>>>>> I'm sorry, there are no details there. There's merely mention of these four being
>>>>> reserved, without supplying any reason (historical or not).
>>>>
>>>> Sorry, you could see https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/6207f9a2c0645f20a7ec591a09e4c382b1675784
>>>> There are reserved for Intel MPX (Memory Protection Extensions) provides 4 128-bit wide bound registers (reg{bnd0} - reg{bnd3}).
>>>
>>> Then why aren't these marked that way? The commit introducing them to
>>> opcodes used Dw2Inval, and it was never changed from that (i.e. there
>>> wasn't even deliberate undoing with respective justification).
>>
>> Leave them as reserved. We have plenty.
>
> Hmm, the latter sentence doesn't fir what I meant: Why does / did
> i386-reg.tbl not / never have those numbers? I could have seen that
> they were there and then possibly have been purged, but even then
> I would expect there a comment to have been left. So minimally what
> I'd like to see / do is to add such comments.
>
Is the patch (opcodes: i386: fix dw2_regnum data type in reg_entry) OK
to commit now ?
Thanks
Indu
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry
2024-01-20 0:45 ` Indu Bhagat
@ 2024-01-22 7:49 ` Jan Beulich
0 siblings, 0 replies; 12+ messages in thread
From: Jan Beulich @ 2024-01-22 7:49 UTC (permalink / raw)
To: Indu Bhagat; +Cc: Kong, Lingling, binutils, Cui, Lili, Hu, Lin1, H.J. Lu
On 20.01.2024 01:45, Indu Bhagat wrote:
> On 1/11/24 06:05, Jan Beulich wrote:
>> On 11.01.2024 14:27, H.J. Lu wrote:
>>> On Thu, Jan 11, 2024 at 12:05 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 11.01.2024 08:59, Kong, Lingling wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>>> Sent: Thursday, January 11, 2024 3:43 PM
>>>>>> To: Kong, Lingling <lingling.kong@intel.com>
>>>>>> Cc: binutils@sourceware.org; Indu Bhagat <indu.bhagat@oracle.com>; Cui, Lili
>>>>>> <lili.cui@intel.com>; H.J. Lu <hjl.tools@gmail.com>; Hu, Lin1
>>>>>> <lin1.hu@intel.com>
>>>>>> Subject: Re: [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry
>>>>>>
>>>>>> On 11.01.2024 02:35, Kong, Lingling wrote:
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>>>>> Sent: Tuesday, January 9, 2024 4:25 PM
>>>>>>>> To: Indu Bhagat <indu.bhagat@oracle.com>; Cui, Lili
>>>>>>>> <lili.cui@intel.com>; H.J. Lu <hjl.tools@gmail.com>; Kong, Lingling
>>>>>>>> <lingling.kong@intel.com>; Hu, Lin1 <lin1.hu@intel.com>
>>>>>>>> Cc: binutils@sourceware.org
>>>>>>>> Subject: Re: [PATCH] opcodes: i386: fix dw2_regnum data type in
>>>>>>>> reg_entry
>>>>>>>>
>>>>>>>> On 09.01.2024 02:12, Indu Bhagat wrote:
>>>>>>>>> The DWARF register numbers for the APX EGRPs start with 130. The
>>>>>>>>> data type holding the same currently is signed char.
>>>>>>>>>
>>>>>>>>> ChangeLog:
>>>>>>>>> * opcodes/i386-opc.h (reg_entry): Bump to signed short.
>>>>>>>>
>>>>>>>> So yes, something needs doing. But there are further questions to be
>>>>>>>> raised to the original authors: Was the code tested at all in this
>>>>>>>> regard? Why do numbers start at 130, when according to i386-reg.tbl
>>>>>>>> 128 and 129 are unused (and would hence be more natural to [also] use)?
>>>>>>>
>>>>>>> This is because for some historical reasons, some numbers(126-129) have been
>>>>>> agreed to be reserved.
>>>>>>> Details can be found in https://groups.google.com/g/x86-64-
>>>>>> abi/c/GS8LZf5nQFk.
>>>>>>
>>>>>> I'm sorry, there are no details there. There's merely mention of these four being
>>>>>> reserved, without supplying any reason (historical or not).
>>>>>
>>>>> Sorry, you could see https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/6207f9a2c0645f20a7ec591a09e4c382b1675784
>>>>> There are reserved for Intel MPX (Memory Protection Extensions) provides 4 128-bit wide bound registers (reg{bnd0} - reg{bnd3}).
>>>>
>>>> Then why aren't these marked that way? The commit introducing them to
>>>> opcodes used Dw2Inval, and it was never changed from that (i.e. there
>>>> wasn't even deliberate undoing with respective justification).
>>>
>>> Leave them as reserved. We have plenty.
>>
>> Hmm, the latter sentence doesn't fir what I meant: Why does / did
>> i386-reg.tbl not / never have those numbers? I could have seen that
>> they were there and then possibly have been purged, but even then
>> I would expect there a comment to have been left. So minimally what
>> I'd like to see / do is to add such comments.
>
> Is the patch (opcodes: i386: fix dw2_regnum data type in reg_entry) OK
> to commit now ?
To be honest - not sure. I'd like to look into avoiding the growth, by
switching to "unsigned char" instead. But that requires changes elsewhere,
because of the need to double-check uses of (and maybe further special-
case) Dw2Inval.
Jan
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2024-01-22 7:49 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-09 1:12 [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry Indu Bhagat
2024-01-09 1:12 ` [PATCH] opcodes: gas: i386: use Rex2 as attribute not constraint Indu Bhagat
2024-01-09 8:14 ` Jan Beulich
2024-01-09 8:24 ` [PATCH] opcodes: i386: fix dw2_regnum data type in reg_entry Jan Beulich
2024-01-11 1:35 ` Kong, Lingling
2024-01-11 7:43 ` Jan Beulich
2024-01-11 7:59 ` Kong, Lingling
2024-01-11 8:05 ` Jan Beulich
2024-01-11 13:27 ` H.J. Lu
2024-01-11 14:05 ` Jan Beulich
2024-01-20 0:45 ` Indu Bhagat
2024-01-22 7:49 ` Jan Beulich
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).