Re: [PATCH] jump_label: align jump_entry table to at least 4-bytes

[David Daney]

On 02/27/2017 02:09 PM, Steven Rostedt wrote:
> On Mon, 27 Feb 2017 13:41:13 -0800
> David Daney <ddaney@xxxxxxxxxxxxxxxxxx> wrote:
>
> > On 02/27/2017 01:06 PM, Steven Rostedt wrote:
> > > On Mon, 27 Feb 2017 11:59:50 -0800
> > > David Daney <ddaney@xxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > > For me the size is not the important issue, it is the alignment of the
> > > > struct jump_entry entries in the table.  I don't understand how your
> > > > patch helps, and I cannot Acked-by unless I understand what is being
> > > > done and can see that it is both correct and necessary.
> > >
> > > You brought up a very good point and I'm glad that I had Jason Cc all
> > > the arch maintainers in one patch.
> > >
> > > I think jump_labels may be much more broken than we think, and Jason's
> > > fix doesn't fix anything. We had this same issues with tracepoints.
> > >
> > > I'm looking at jump_label_init, and how we iterate over an array of
> > > struct jump_entry's that was put together by the linker. The problem is
> > > that jump_entry is not a power of 2 in size.
> >
> > ELF sections may have an ENTSIZE property exactly for arrays.  Since
> > each jump_entry will have a unique value they cannot be merged, but we
> > can tell the assembler they are an array and get them properly packed.
> > Perhaps something like (untested):
> >
> >     .pushsection __jump_table,  \"awM\",@progbits,24
> >     FOO
> >     .popsection
>
> And the linker will honor this too?

See attached for mips.  It seems to do the right thing.

I leave it as an exercise to the reader to fix the other architectures.

Consult your own  binutils experts to verify that what I say is true.


David Daney