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? > 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 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? > 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. ~Andrew
