Re: [PATCH] x86: adjust which Dwarf2 register numbers to use

[Jan Beulich <jbeulich@suse.com>]

On 21.02.2024 00:04, Indu Bhagat wrote:
> On 2/15/24 23:26, Jan Beulich wrote:
>> On 15.02.2024 23:22, Indu Bhagat wrote:
>>> On 2/9/24 00:11, Jan Beulich wrote:
>>>> Consumers can't know which execution mode is in effect for a certain
>>>> piece of code; they can only go from object file properties. Hence which
>>>> register numbers to encode ought to depend solely on object file type.
>>>>
>>>> --- a/gas/config/tc-i386.c
>>>> +++ b/gas/config/tc-i386.c
>>>> @@ -5409,7 +5409,7 @@ ginsn_dw2_regnum (const reg_entry *ireg)
>>>>      if (ireg->reg_num == RegIP || ireg->reg_num == RegIZ)
>>>>        return GINSN_DW2_REGNUM_RSI_DUMMY;
>>>>    
>>>> -  dwarf_reg = ireg->dw2_regnum[flag_code >> 1];
>>>> +  dwarf_reg = ireg->dw2_regnum[object_64bit];
>>>>    
>>>>      if (dwarf_reg == Dw2Inval)
>>>>        {
>>>> @@ -17461,7 +17461,7 @@ tc_x86_parse_to_dw2regnum (expressionS *
>>>>          if ((addressT) exp->X_add_number < i386_regtab_size)
>>>>    	{
>>>>    	  exp->X_add_number = i386_regtab[exp->X_add_number]
>>>> -			      .dw2_regnum[flag_code >> 1];
>>>> +			      .dw2_regnum[object_64bit];
>>>>    	  if (exp->X_add_number != Dw2Inval)
>>>>    	    exp->X_op = O_constant;
>>>>    	}
>>>
>>> On one hand, I see that the suggested code changes are making things
>>> semantically clearer, I would like to understand:
>>>
>>> 1. If there is a scenario where flag_code is CODE16_BIT / CODE32_BIT and
>>> object_64bit equal to 1 is supported.  gcc passes --32 when using -m16
>>> or -m32.
>>
>> Well, gcc may never produce such input, but hand-written assembly can.
> 
> Then, should we also use sp[object_64bit] instead of sp[flag_code >> 1] 
> in tc_x86_frame_initial_instructions? Otherwise the assert "gas_assert 
> (exp.X_op == O_constant)" will trigger, e.g. with .code16 and --64.

Indeed. Need to make a v3 then, and probably go hunt for any other
"flag_code >> 1". It's really odd how "well" those uses are scattered
across, with no mention of the need to stay in sync (which wouldn't
have been much of a problem if it had been got right from the
beginning).

Of course I question the invocation of parsing a register name there;
the two numbers that can result are well known. Parsing would perhaps
be warranted if, say, for COFF different numbers would result (and
hence determining them at build time wouldn't be as easy). So I may
end up simplifying this beyond just switching to use of object_64bit.

Jan