Frantisek Hrbata <fhrbata@xxxxxxxxxx> writes: > On Tue, Sep 10, 2013 at 03:05:57PM +0930, Rusty Russell wrote: >> Frantisek Hrbata <fhrbata@xxxxxxxxxx> writes: >> > On Mon, Sep 09, 2013 at 10:44:03AM +0930, Rusty Russell wrote: >> >> Kyle McMartin <kyle@xxxxxxxxxxxxx> writes: >> >> > On Fri, Sep 06, 2013 at 07:51:18PM +0200, Frantisek Hrbata wrote: >> >> >> > > v2: - reuse mod->ctors for .init_array section for modules, because gcc uses >> >> >> > > .ctors or .init_array, but not both at the same time >> >> >> > > >> >> >> > > Signed-off-by: Frantisek Hrbata <fhrbata@xxxxxxxxxx> >> >> >> > >> >> >> > Might be nice to document which gcc version changed this, so people can >> >> >> > choose whether to cherry-pick this change? >> >> >> >> >> >> Thank you for pointing this out. As per gcc git this was introduced by commit >> >> >> ef1da80 and released in 4.7 version. >> >> >> >> >> >> $ git describe --contains ef1da80 >> >> >> gcc-4_7_0-release~4358 >> >> >> >> >> >> Do you want me to post v3 with this info included in the descrition? >> >> >> >> >> > >> >> > It actually depends on the combination of binutils/ld and gcc you use, not >> >> > simply which gcc version you use. :/ >> >> >> >> Indeed, and seems it was binutils 20110507 which actually handled it >> >> properly. >> >> >> >> AFAICT it's theoretically possible to have .ctors and .init_array in a >> >> module. Unlikely, but the patch should check for both and refuse to >> >> load the module in that case. Otherwise weird things would happen. >> > >> > 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"? >> >> Well, if we have both ctors and init_array, and we only call the ctors, >> part of the module will be uninitialized. >> >> I was thinking about something like the following (based on your >> previous patch). >> >> Thoughts? >> Rusty. > > Thank you Rusty, from what I can say it looks ok to me. So I would go with this > version. Is there anything that needs to be done to consider this as the > correct version of the 4/4 patch? Meaning should we repost this as v3 or could > your version of the patch be picked as you posted it? Take that as posted. I could push it through my tree, but I think you'll want to keep them all together. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html