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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.03.2025 17:39, Andrew Cooper wrote:
> On 13/03/2025 1:54 pm, Jan Beulich wrote:
>> When determining the symbol for a given address (e.g. for the %pS
>> logging format specifier), so far the size of a symbol (function) was
>> assumed to be everything until the next symbol. There may be gaps
>> though, which would better be recognizable in output (often suggesting
>> something odd is going on).
> 
> Do you have an example %pS for this new case?

I haven't encountered one yet, and I wasn't particularly trying to
make up one.

>> Insert "fake" end symbols in the address table, accompanied by zero-
>> length type/name entries (to keep lookup reasonably close to how it
>> was).
>>
>> Note however that this, with present GNU binutils, won't work for
>> xen.efi: The linker loses function sizes (they're not part of a normal
>> symbol table entry), and hence nm has no way of reporting them.
> 
> By "present GNU binutils", does this mean that you've got a fix in mind
> (or in progress), or that it's an open problem to be solved?

The latter; I can't even tell yet whether this is legitimate to be
arranged for in a PE executable's symbol table.

>> The address table growth is quite significant on x86 release builds (due
>> to functions being aligned to 16-byte boundaries), though: Its size
>> almost doubles.
> 
> Why does the function alignment affect the growth?

I only insert fake end symbols when the following symbol doesn't match
the prior one's end. Hence with minimal alignment (and thus no gaps)
there wouldn't be any "end" symbols at all.

>> Requested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> Note: Style-wise this is a horrible mix. I'm trying to match styles with
>>       what's used in the respective functions.
>>
>> Older GNU ld retains section symbols, which nm then also lists. Should
>> we perhaps strip those as we read in nm's output? They don't provide any
>> useful extra information, as our linker scripts add section start
>> symbols anyway. (For the purposes here, luckily such section symbols are
>> at least emitted without size.)
> 
> Will symbols_lookup() ever produce these?  If not, it might be better to
> ignore the problem.
> 
> Taking extra logic to work around a benign issue in older toolchains
> isn't necessarily ideal.

Afaict it's unpredictable from Xen's pov. All depends on the order of
entries after we sorted the table by address. The only criteria the
tool's compare_value() applies for multiple symbols at the same address
is to prefer global over local. As long as the first symbol in a section
is global, we wouldn't see section symbols as lookup result.

Jan