[PATCH,V2] readelf: objdump: sframe: fix dumping with section name

[Jan Beulich]

On 24.07.2025 18:57, Indu Bhagat wrote:
> On 7/24/25 8:09 AM, Jan Beulich wrote:
>> On 23.07.2025 08:41, Indu Bhagat via Binutils wrote:
>>> @@ -4999,6 +5002,18 @@ dump_sframe_section (bfd *abfd, const char *sect_name, bool is_mainfile)
>>>         printf (_("No %s section present\n\n"), sanitize_string (sect_name));
>>>         return;
>>>       }
>>> +      /* Starting with Binutils 2.45, SFrame sections have section type
>>> +     SHT_GNU_SFRAME.  For SFrame sections from Binutils 2.44 or earlier,
>>> +     check explcitly for SFrame sections of type SHT_PROGBITS and name
>>> +     ".sframe." to allow them.  */
>>
>> There's a seemingly stray dot in the quoted section name.
>>
>> Okay with that adjustment (or a clarification of what I'm missing),
>> even if I'm not entirely happy with the overall behavior (as previously
>> noted).
>>
> 
> (Sorry, looks like I missed some of your concerns then.)
> What is the concern that needs clarification ?
> 
> I am aware of the recommendation for the --sframe option to rather behave as:
> 
>   - objdump and readelf dump SHT_GNU_SFRAME sections when presented with --sframe irrespective of the name.  If there are multiple SHT_GNU_SFRAME, they be dumped with --sframe.
> 
>   - objdump and readelf continue to dump specific SFrame sections by name if user specifies --sframe=<section-name>.
> 
> To do the above, we need to remove the "default: .sframe" from the publicized options.

This is the remaining concern, and ...

>  I did not prefer to do that at this time as I want to backport this patch to 2.45 (still to ask Nick).  FWIW, most users will not hit the need for above IMO, but I will see if I can get to this later for 2.46.

... this is why I gave my okay nevertheless.

Jan