lkml.org 
[lkml]   [2013]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 4/4] kernel: add support for init_array constructors
On Mon, Sep 09, 2013 at 06:28:14PM +0200, Frantisek Hrbata wrote:
> I'm not sure if coexistence of .ctors and .init_array sections should result in
> denial of module, but I for sure know nothing about this :). Could you maybe
> privide one example of the "weird thing"?
>

They shouldn't exist unless placed there intentionally... I suspect a
call_if_changed Makefile target to regenerated a header would solve this
problem sufficiently for a given toolchain version.

A little exposition:
.init_array and .ctors are laid out on top of each other, with an
ordering that's a bit complicated... the sort of the ctor functions ends
up being .ctor.x upwards towards 65535, and .init_array.x downwards
from 65535 towards 0, with priority 65535-x, so that

.init_array.32768 would be called before .ctor.32768.

It's all a complete mess.

Perhaps if CONFIG_GCOV is on, we should enforce MODVERSIONS and make
sure the GCC version doesn't change for the running kernel?

Maybe it would be sufficient to just detect what the toolchain supports
and do that? I have a patch based on the configure.ac in gcc that
does something like that, which would be trivial to use to generate a
header based on gcc version.

> Anyway many thanks for taking time to look at this. Below is my attepmt to
> implement the check you proposed.
>
> untested/uncompiled

regards, Kyle


\
 
 \ /
  Last update: 2013-09-10 02:41    [W:0.113 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site