gcc bug causing problem in kernel builds

We have been experiencing some problems trying to use kernel modules with kernels that are compiled with different versions of gcc. On our kernel build machine (where we compile our kernel modules) we have gcc 2.91.66 (I believe the preferred kernel compiler, according to Documentation/Changes); RedHat 7.1 ships with gcc 2.96.

Now, the problem is that RedHat also apparently compiles (at least its newer) kernels with the 2.96 gcc. Unfortunately, there appears to be a structure misalignment problem in gcc 2.96.

One particular instance of this problem that we are running into is in the raid1.o module in the 2.4.3 kernel. The structure alignment problem is causing our gcc 2.91.66-compiled raid1 module to malfunction. (raid1.o compiled from the same source on gcc 2.96 works fine.) We've traced the problem down to the following assembly code generated by the 2.96 and 2.91.66 gcc's respectively:

(assembly code for parameter setup and call to __alloc_pages (within raid1_grow_buffers))

2.96:

movl $contig_page_data_Rsmp_cef82582+3800, %eax
call __alloc_pages_Rsmp_decacc2f

2.91.66:

movl $contig_page_data_Rsmp_cef82582+3884,%eax
call __alloc_pages_Rsmp_decacc2f

gcc 2.91.66 is padding out the zone_t structure by 28 bytes. With an array of 3 of those before our field in question that equals 84 bytes offset in the above assembler code.

The 28 byte padding is because gcc 2.91.66 is trying to 32 byte align this structure. The reason for this is that the first submember of zone_t is explicitly defined as 32 byte aligned (per_cpu_t).

So, gcc 2.91.66 is (properly) aligning the per_cpu_t structure on a 32 byte boundary as specified by the __attribute__((aligned(32))) directive in that structure's definition:

(gdb) p &((pg_data_t *)0)->node_zones[1].cpu_pages[0] $22 = (per_cpu_t *) 0x4e0

(gdb) p &((pg_data_t *)0)->node_zones[1].cpu_pages[1] $23 = (per_cpu_t *) 0x500

(gdb) p 0x500 % 32
$24 = 0

(gdb) p 0x4e0 % 32
$25 = 0

gcc 2.96 is not properly aligning this structure:

(gdb) p &((pg_data_t *)0)->node_zones[1].cpu_pages[0] $32 = (per_cpu_t *) 0x4c4

(gdb) p &((pg_data_t *)0)->node_zones[1].cpu_pages[1] $33 = (per_cpu_t *) 0x4e4

(gdb) p 0x4c4 % 32
$34 = 4

(gdb) p 0x4e4 % 32
$35 = 4

So, in order for our raid1 modules to work properly with a kernel compiled by gcc 2.96, we must also use (the broken) 2.96 to compile our module.

So I guess some of the questions that arise from all this are:

Does anyone know if the structure misalignment problem in gcc 2.96 is a known issue? (could this bug be induced by a RedHat-applied gcc patch, if there are any)

How widespread is this problem? i.e., do other distributions have similar issues?, do other versions of gcc have similar issues?, are there other places in the kernel where this type of problem might occur?

I'll also post to gcc bug list.

----
Paul

[email protected]

The kernel is compiled with some objects differently according to the compiler features. In paticular we have to pad out structures with 0 length elements in the older compilers to fix a compiler bug. You must compile with the same precise compiler and options as the kernel itself.

gcc 2.96-54 had plenty of bugs, 2.96-75+ should be perfectly fine for all uses. If you have a 2.96 RH problem please report it in Red Hat bugzilla - the gcc core folks won't be too interested as they are focused on 2.95.4 and 3.0.1 bug fixing.

Alan

Uh oh... the gcc 2.96 I'm using is:

# rpm -q gcc
gcc-2.96-81

Will do.

Thanks,
Paul

[email protected]

There are some patches applied (something like ~350 patches), but as gcc 3.0.1 and gcc CVS head behave the same way as gcc-2.96-RH, it is not RH specific.
Looking into it.

Jakub