[PATCH 2/3] libsframe: testsuite: refactor findfre-1 for clarity

[Indu Bhagat]

On 5/20/25 11:20 PM, Jan Beulich wrote:
> On 20.05.2025 21:03, Indu Bhagat wrote:
>> The testcase had usages of some magic numbers, making it difficult to
>> keep up when format changes come along.
> 
> Yet there are still several magic numbers, with not even a hint what they
> derive from, like ...
> 
>> --- a/libsframe/testsuite/libsframe.find/findfre-1.c
>> +++ b/libsframe/testsuite/libsframe.find/findfre-1.c
>> @@ -28,9 +28,9 @@
>>   #include <dejagnu.h>
>>   
>>   static int
>> -add_fde1 (sframe_encoder_ctx *encode, int idx)
>> +add_fde1 (sframe_encoder_ctx *encode, unsigned int start_pc_vaddr,
>> +	  unsigned int sframe_vaddr, int idx, unsigned int *func_size)
>>   {
>> -  int i, err;
>>     /* A contiguous block containing 4 FREs.  */
>>     sframe_frame_row_entry fres[]
>>       = { {0x0, {0x1, 0, 0}, 0x3},
>> @@ -38,24 +38,27 @@ add_fde1 (sframe_encoder_ctx *encode, int idx)
>>   	{0x10, {0x3, 0xf0, 0}, 0x4},
>>   	{0x38, {0x8, 0xf0, 0}, 0x5}
>>         };
>> +  *func_size = 0x40;
> 
> ... this one. I can't decide why it's 0x40 here, and it's well possible
> the number is simply made up arbitrarily. A brief comment on each of
> them may help.
> 

I have added a comment for now, for func_size here and other places 
(across the three tests).  Something like:

  /* Function size in bytes.  P.S. Must be a value greater than the
     fre_start_addr of the last FRE above (0x38).  */

Some other magic number usages remain as you point out, especially those 
around the FRE data.  But perhaps those usages are maintainable for now.