On 10/29/25 2:34 PM, Jan Beulich wrote:
symbols-dummy.c and the generated .xen-syms.?.S may place their symbols in
different sections: Like for all C files, -fdata-sections may be in effect
there. As a result, besides moving these symbols may then also have
different amounts of "end" symbols inserted between them. While the
movement is likely not problematic, the change in table size is - linking
passes 2 and 3 want no address (and hence no size) changes between them.
As, at least right now, the "end" symbols are useful only for code, limit
their emission accordingly. When data symbols are emitted (i.e. when
LIVEPATCH=y), this obviously also has a positive effect on overall table
size (I'm seeing almost 600 entries going away in the build I'm looking
at).
Fixes: d3b637fba31b ("symbols: arrange to know where functions end")
Reported-by: Roger Pau Monné<[email protected]>
Signed-off-by: Jan Beulich<[email protected]>
Release-Acked-By: Oleksii Kurochko<[email protected]>
Thanks.
~ Oleskii
---
Furthermore at least some gcc versions emit the (read-only) data there into
.bss.symbols_* rather than the expected (but still potentially problematic)
.rodata.symbols_*.
--- a/xen/tools/symbols.c
+++ b/xen/tools/symbols.c
@@ -176,10 +176,9 @@ static int read_symbol(FILE *in, struct
*sym++ = '#';
}
strcpy(sym, str);
- if (sort_by_name || map_only) {
+ if (sort_by_name || map_only)
s->orig_symbol = strdup(SYMBOL_NAME(s));
- s->type = stype; /* As s->sym[0] ends mangled. */
- }
+ s->type = stype; /* As s->sym[0] may end up mangled. */
s->sym[0] = stype;
s->typed = strcmp(type, "FUNC") == 0 ||
strcmp(type, "OBJECT") == 0 ||
@@ -313,6 +312,7 @@ static int compare_name_orig(const void
static bool want_symbol_end(unsigned int idx)
{
return table[idx].size &&
+ toupper(table[idx].type) == 'T' &&
(idx + 1 == table_cnt ||
table[idx].addr + table[idx].size < table[idx + 1].addr);
}
