On 29.10.2025 16:13, Andrew Cooper wrote: > On 29/10/2025 1: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. > > Sorry, I can't parse this sentence. Do you mean "these symbols, there > may also be" ?
Oh, yes, I screwed up there. (I think it read half-way sensible to me when inserting a mental comma after "moving".) Really I'm intending to go with "... besides these symbols moving, there may then also be ..." >> 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). > > Xen-crashdump-analyser needs end in System.map, and I expect so does > `crash`. > > As this patch only adjusts the embedded symbol table, I think that's all > fine? I think so. With "end" (quoted) I never mean symbols with the name 'end' here, but rather those that tools/symbols injects (as unnamed ones). No symbols with names (including ones named 'end') will be affected / removed. (I think though that it's '_end' anyway that you mean.) Jan
