Re: [PATCH for-4.21] symbols: avoid emitting "end" symbols for data items

[Jan Beulich <jbeulich@suse.com>]

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