Bug#808246: Potentially interesting difference in module header symbol order
On Mon, Dec 21, 2015 at 12:19:17PM -0500, wrote:
> I was looking at the module headers and found this pattern:
>
> In 4.2.1-2, 4.2.5-1, and 4.2.6-1 the order of the header for fat.ko says:
>
> 17 .data.rel.ro 000001c0 0000000000000000 0000000000000000 00011418 2**3
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 18 .opd 00000af8 0000000000000000 0000000000000000 000115d8 2**3
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 19 .toc 00000440 0000000000000000 0000000000000000 000120d0 2**0
> CONTENTS, ALLOC, LOAD, RELOC, DATA
>
> While in 4.2.6-2, 4.2.6-3 4.3.1-1 and 4.3.3-1 it says:
>
> 17 .opd 00000af8 0000000000000000 0000000000000000 00011418 2**3
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 18 .toc 00000440 0000000000000000 0000000000000000 00011f10 2**0
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 19 .data.rel.ro 000001b0 0000000000000000 0000000000000000 00012350 2**3
> CONTENTS, ALLOC, LOAD, RELOC, DATA
>
> So the .toc used to be after .data.rel.ro and opd, and now it isn't.
> Maybe that is causing the issue, or at least points at where the
> problem is.
>
> At least the working kernels have one pattern and all the broken kernels
> have another pattern.
I tried various binutils versions, and any version starting from
2.25.51.20151014-1 seems to be reordering the sections, even though
the arch/powerpc/kernel/vmlinux.lds file explicitly says to use the
order with .toc at the end. So somehow binutils 2.25.51+ is ignoring
instructions about which order to put things in the file, which seems
like it is causing the kernel to not be able to load modules.
Simply reverting to binutils 2.25.1-7 makes the modules build like they
did before, so it does not seem to be gcc or anything else at fault,
just the new binutils.
Since most architectures probably don't have anything like the .toc,
it is likely only powerpc64 is affected.
--
Len Sorensen
Reply to: