[PATCH] gas/CFI: fix .cfi_escape parsing when equates are in use

[Jan Beulich]

On 24.12.2025 10:50, Indu Bhagat wrote:
> On 12/22/25 2:22 AM, Jan Beulich wrote:
>> On 20.12.2025 06:11, Indu wrote:
>>> On 2025-12-18 7:07 a.m., Jan Beulich wrote:
>>>> @@ -1010,7 +1009,7 @@ dot_cfi_escape (int ignored ATTRIBUTE_UN
>>>>    	}
>>>>          else
>>>>    	{
>>>> -	  /* We may still be at the opening parenthesis.  Leave it to expression()
>>>> +	  /* We may still be at an opening parenthesis.  Leave it to expression()
>>>>    	     to parse it and find the matching closing one.  */
>>>>    	  e->reloc = do_parse_cons_expression (&e->exp, e->type);
>>>
>>> Unrelated to the current patch, I am wondering what is the expected
>>> e->reloc for the case when e->type is CFI_ESC_sleb128 or CFI_ESC_uleb128.
>>
>> None in the common case. Very few targets have suitable relocations, which
>> is reflected by there being very few BFD_RELOC_*LEB128*. This could likely
>> be generalized some, but it wouldn't buy us much here: The reloc type then
>> would merely be redundant with CFI_ESC_{s,u}leb128 in e->type.
>>
> 
> Is the following in gas/dw2gencfi.c appropriate to do then?
> 
> --- a/gas/dw2gencfi.c
> +++ b/gas/dw2gencfi.c
> @@ -1006,6 +1006,7 @@ dot_cfi_escape (int ignored ATTRIBUTE_UNUSED)
>            /* We're still at the opening parenthesis.  Leave it to 
> expression()
>               to parse it and find the matching closing one.  */
>            expression (&e->exp);
> +         e->reloc = TC_PARSE_CONS_RETURN_NONE;
>          }
>         else
>          {
> 
> Basically for admission control of specific .cfi_escape patterns,  so 
> far, the code checks for reloc too.  To make sleb128 permissible, I need 
> to pin down the admissibility criteria for it, perferably including the 
> reloc.

Yes, if the field needs looking at without qualifying by e->type, then setting
it like you do is of course both needed and appropriate.

Jan