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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 13/03/2025 4:48 pm, Jan Beulich wrote:
> 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.

In which case, I'd suggest using the phrase "open problem" to make it
clear that there's no fix.

>
>>> 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.

Hmm, thinking about it, the global-ness does cause problems.

e.g. we get _stextentry()+x rather than restore_all_guest()+x, and RAG
is more likely than some to show up in a backtrace.

So maybe we should strip section symbols, even the explicit linker ones,
from the symbol table.  I can't offhand think of a case where we want to
look up a symbol by address and get back a section name.

(Feel free to leave this as a todo.  I wasn't intending to scope creep
like this, but it would be a nice to have.)

~Andrew