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.coop...@citrix.com> >>> Signed-off-by: Jan Beulich <jbeul...@suse.com> >>> --- >>> 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
