* [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).