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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.03.2025 18:13, Andrew Cooper wrote:
> 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.

I'd like to leave it as is; right here it's not overly important what
state the binutils side is. Furthermore, by the time this goes in the
binutils side may have changed state already (e.g. from "open problem" to
"fix in progress").

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

So one thing we could do is to prefer FUNC/OBJECT symbols over NOTYPE
ones, and only use global-ness as a last resort criteria.

But "prefer" != "strip" in any event.

Stripping section symbols is reasonably easy for ELF, as rather than
being NOTYPE they have no type at all. Stripping section start symbols,
otoh, can only be done by name, and hence we'd need to maintain a list
of them in the symbols tool. Not overly nice, but doable of course.

An intrusive - to the symbol table - alternative may be to simply strip
all NOTYPE symbols. Yet that would take as a prereq marking quite a few
more as FUNC or OBJECT.

>  I can't offhand think of a case where we want to
> look up a symbol by address and get back a section name.

We also need to keep in mind the opposite (lookup by name) for livepatch.
I for one have no idea how (un)likely it might be for there to be a need
to lookup a section symbol (then we'd be in trouble with newer binutils)
or a section start symbol.

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

If we can agree on what behavior we want, I can see about adding further
patches to the series.

Jan