Re: [PATCH v2 3/5] symbols: arrange to know where functions end

[Jason Andryuk <jason.andryuk@xxxxxxx>]

On 2025-08-28 12:11, Jan Beulich wrote:
> On 28.08.2025 09:28, Jan Beulich wrote:
> > On 28.08.2025 03:03, Jason Andryuk wrote:
> > > On 2025-04-02 09:58, Jan Beulich wrote:
> > > > --- a/xen/tools/symbols.c
> > > > +++ b/xen/tools/symbols.c
> > > > @@ -318,24 +334,42 @@ static void write_src(void)
> > > >         printf("#else\n");
> > > >         output_label("symbols_offsets");
> > > >         printf("#endif\n");
> > > > -       for (i = 0; i < table_cnt; i++) {
> > > > +       for (i = 0, ends = 0; i < table_cnt; i++) {
> > > >                 printf("\tPTR\t%#llx - SYMBOLS_ORIGIN\n", table[i].addr);
> > > > +
> > > > +               table[i].addr_idx = i + ends;
> > > > +
> > > > +               if (!want_symbol_end(i)) {
> > > > +                       /* If there's another symbol at the same address,
> > > > +                        * propagate this symbol's size if the next one has
> > > > +                        * no size, or if the next one's size is larger. */
> > > Why do we want to shrink the next symbol's size?
> > First (see related post-commit-message remarks): In principle section symbols
> > could come with a size, too. That would break everything as long as we don't
> > strip those.
> >
> > The main reason though is that imo smallest granularity is what we want here,
> > together with predictability. One symbol with a huge size could cover
> > multiple other symbols with smaller sizes. We could omit that part of the
> > change here, but then the processing in the hypervisor would need to change,
> > to fish out the "best suitable" symbol when dealing with multiple ones at the
> > same address. Other changes may then also be needed to the tool, to have such
> > symbols come in a well-defined order (to keep the then-new code in the
> > hypervisor as simple as possible). Look for "aliased symbol" in
> > common/symbols.c to see how simplistic respective code is right now.
> Furthermore remember that we can't record sizes, but instead we insert fake
> symbols. Obviously there can be only one (at least in the present scheme).
> If we used too large a size, chances would increase that the end symbol (in
> the sorted table) would have to live past some other symbol, thus becoming
> that one's "end".
The scenario I thought about is something like:

a 0x100-0x10f
b 0x100-0x1ff
c 0x200-0x2ff

If you shrink b, you are creating a hole that would otherwise be 
assigned to b.
But I agree avoiding huge sizes covering multiple small variables would 
better be avoided.
Do you have concrete examples to help illustrate the problem?

Regards,
Jason