On Thu, Jun 23, 2016 at 3:19 PM, Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote: > On Thu, Jun 23, 2016 at 3:06 PM, Andrey Ryabinin <ryabinin.a.a@xxxxxxxxx> wrote: >> 2016-06-23 15:40 GMT+03:00 Dmitry Vyukov <dvyukov@xxxxxxxxxx>: >>> On Thu, Jun 23, 2016 at 1:50 PM, Andrey Ryabinin <ryabinin.a.a@xxxxxxxxx> wrote: >>>> 2016-06-23 14:49 GMT+03:00 Andrey Ryabinin <ryabinin.a.a@xxxxxxxxx>: >>>> >>>>> Frankly, I don't understand why .text.[exit,startup] sections has any relation >>>>> to the bug you described, but maybe I just don't now linker >>>> >>>> ... scripting well enough to understand what's going on here. >>> >>> >>> I noticed that these 3 new sections are what's different between >>> kernel that works and kernel that does not work. So I decided to >>> account all of them >>> Checked now, it works only with .dtors. >>> Is it preferable to add only .dtors or all sections? >> >> No. Merging text.startup/text.exit into INIT_TEXT/EXIT_TEXT makes sense anyway. >> This will save us some memory. Also we can add .fini_array into >> DISCARD section, because we don't need destructors. >> >> As for .dtors, at first I'd like to understand where it comes from. >> AFAIU it shouldn't exist at all. >> Recent gcc should generate .fini_array instead of .dtors - >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 >> So something is wrong here. Can you share your kernel .config, kernel version? >> And you use gcc-6.1.0, right? > > gcc version 6.1.1 20160513 > > .dtors contains asan destructors for global vars: > > [18] .dtors PROGBITS ffffffff8279a600 016c7600 > 0000000000002e20 0000000000000000 WA 0 0 8 > > 016c7600 00 1b b4 81 ff ff ff ff 20 1b b4 81 ff ff ff ff |........ .......| > 016c7610 40 1b b4 81 ff ff ff ff 60 1b b4 81 ff ff ff ff |@.......`.......| > 016c7620 80 1b b4 81 ff ff ff ff a0 1b b4 81 ff ff ff ff |................| > 016c7630 c0 1b b4 81 ff ff ff ff e0 1b b4 81 ff ff ff ff |................| > > vmlinux.old:ffffffff81b41b20 0000000000000017 t > _GLOBAL__sub_D_65535_0_init_uts_ns > vmlinux.old:ffffffff81b41b40 0000000000000017 t > _GLOBAL__sub_D_65535_0_root_mountflags > vmlinux.old:ffffffff81b41b60 0000000000000017 t _GLOBAL__sub_D_65535_0_rd_prompt > vmlinux.old:ffffffff81b41b80 0000000000000017 t > _GLOBAL__sub_D_65535_0_initrd_load > > ffffffff81b41b20 <_GLOBAL__sub_D_65535_0_init_uts_ns>: > ffffffff81b41b20: 55 push %rbp > ffffffff81b41b21: be 03 00 00 00 mov $0x3,%esi > ffffffff81b41b26: 48 c7 c7 a0 23 21 82 mov $0xffffffff822123a0,%rdi > ffffffff81b41b2d: 48 89 e5 mov %rsp,%rbp > ffffffff81b41b30: e8 9b 85 83 ff callq > ffffffff8137a0d0 <__asan_unregister_globals> > ffffffff81b41b35: 5d pop %rbp > ffffffff81b41b36: c3 retq > ffffffff81b41b37: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1) > ffffffff81b41b3e: 00 00 gcc/asan.c seems to use plain dtors: fn = builtin_decl_implicit (BUILT_IN_ASAN_UNREGISTER_GLOBALS); append_to_statement_list (build_call_expr (fn, 2, build_fold_addr_expr (var), gcount_tree), &dtor_statements); cgraph_build_static_cdtor ('D', dtor_statements, priority); -- 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
