Re: [PATCH v2 3/5] symbols: arrange to know where functions end

[Jason Andryuk <jason.andryuk@amd.com>]

On 2025-08-28 12:11, Jan Beulich wrote:
> On 28.08.2025 09:28, Jan Beulich wrote:
>> On 28.08.2025 03:03, Jason Andryuk wrote:
>>> On 2025-04-02 09:58, Jan Beulich wrote:
>>>> --- a/xen/tools/symbols.c
>>>> +++ b/xen/tools/symbols.c
>>>
>>>> @@ -318,24 +334,42 @@ static void write_src(void)
>>>>    	printf("#else\n");
>>>>    	output_label("symbols_offsets");
>>>>    	printf("#endif\n");
>>>> -	for (i = 0; i < table_cnt; i++) {
>>>> +	for (i = 0, ends = 0; i < table_cnt; i++) {
>>>>    		printf("\tPTR\t%#llx - SYMBOLS_ORIGIN\n", table[i].addr);
>>>> +
>>>> +		table[i].addr_idx = i + ends;
>>>> +
>>>> +		if (!want_symbol_end(i)) {
>>>> +			/* If there's another symbol at the same address,
>>>> +			 * propagate this symbol's size if the next one has
>>>> +			 * no size, or if the next one's size is larger. */
>>>
>>> Why do we want to shrink the next symbol's size?
>>
>> First (see related post-commit-message remarks): In principle section symbols
>> could come with a size, too. That would break everything as long as we don't
>> strip those.
>>
>> The main reason though is that imo smallest granularity is what we want here,
>> together with predictability. One symbol with a huge size could cover
>> multiple other symbols with smaller sizes. We could omit that part of the
>> change here, but then the processing in the hypervisor would need to change,
>> to fish out the "best suitable" symbol when dealing with multiple ones at the
>> same address. Other changes may then also be needed to the tool, to have such
>> symbols come in a well-defined order (to keep the then-new code in the
>> hypervisor as simple as possible). Look for "aliased symbol" in
>> common/symbols.c to see how simplistic respective code is right now.
> 
> Furthermore remember that we can't record sizes, but instead we insert fake
> symbols. Obviously there can be only one (at least in the present scheme).
> If we used too large a size, chances would increase that the end symbol (in
> the sorted table) would have to live past some other symbol, thus becoming
> that one's "end".

The scenario I thought about is something like:

a 0x100-0x10f
b 0x100-0x1ff
c 0x200-0x2ff

If you shrink b, you are creating a hole that would otherwise be 
assigned to b.

But I agree avoiding huge sizes covering multiple small variables would 
better be avoided.

Do you have concrete examples to help illustrate the problem?

Regards,
Jason