$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC) Recently, linux kernel introduced a security feature[*] to randomize the layout of some crucial structures during compilation. [*]https://lwn.net/Articles/722293/ FYI: the plugin related source files locate: scripts/gcc-plugins/Makefile scripts/gcc-plugins/gen-random-seed.sh scripts/gcc-plugins/randomize_layout_plugin.c of linux kernel source. After enable/disable this feature, I use "gdb vmlinux" to examine the debuginfo, and find that the output of "ptype struct xxx"(xxx is the randomized structure like uts_namespace) in both condition are identical, which feels like a bug to me. And this result would affect other utility like crash tool.
Plugins issues like this should reported to the plugin author and not to gcc.
(In reply to Andrew Pinski from comment #1) > Plugins issues like this should reported to the plugin author and not to gcc. I don't know gcc internals, from my very limited understanding about gcc & that plugin, the plugin just does one optimization on the intermediate language: redefine a structure with randomized order and set it back to its context. So the backend would see a structure different from its original definition in source file and could generate the proper debuginfo. So I feels this issue may be more close to gcc. I was not sure where should I report this problem. I was hoping gcc guys could take a look at that plugin, I feel it is not hard for you gcc expert to read, even I can tell the basic logic inside.
(In reply to Andrew Pinski from comment #1) > Plugins issues like this should reported to the plugin author and not to gcc. what makes you think it's a plugin issue? i reported several gcc bugs myself over the years that i ran across while developing plugins (some have yet to be addressed fwiw). this case is no different, it's a gcc bug where sometimes gcc emits debug info for a type that has not even been constructed yet.
(In reply to Cao jin from comment #2) > (In reply to Andrew Pinski from comment #1) > > Plugins issues like this should reported to the plugin author and not to gcc. > > I don't know gcc internals, from my very limited understanding about gcc & > that plugin, the plugin just does one optimization on the intermediate > language: redefine a structure with randomized order and set it back to its > context. So the backend would see a structure different from its original > definition in source file and could generate the proper debuginfo. So I > feels this issue may be more close to gcc. > > I was not sure where should I report this problem. I was hoping gcc guys > could take a look at that plugin, I feel it is not hard for you gcc expert > to read, even I can tell the basic logic inside. It is not the job of gcc developers to figure out a bug in a plugin or gcc. It is plugin writer's job to do that. (In reply to PaX Team from comment #3) > (In reply to Andrew Pinski from comment #1) > > Plugins issues like this should reported to the plugin author and not to gcc. > what makes you think it's a plugin issue? i reported several gcc bugs myself > over the years that i ran across while developing plugins (some have yet to > be addressed fwiw). this case is no different, it's a gcc bug where > sometimes gcc emits debug info for a type that has not even been constructed > yet. Because debug information happens early on and has many interactions with the front end. Most optimizations don't change types. In fact changing of the type after the fact is not the correct approach, you need to duplication the type and then lay it out and change all of the ir. This is how struct reorg would work. Also you have to check to make sure the types don't escape. Now of that code exists in gcc right now. So again this is outside of the scope of gcc bug.
(In reply to Andrew Pinski from comment #4) > Because debug information happens early on and has many interactions with > the front end. FINISH_TYPE happens early on too and the API promise gcc makes is that it's invoked "After finishing parsing a type" (in practice that's right after c_parser_struct_or_union_specifier for this case). clearly there's a sequencing problem between this and the emission of debug information which means it's either undocumented (gcc bug) or unintended (gcc bug). i don't know which it is but clearly something is not right.
This is a massive issue. https://www.plastererswollongong.com.au
I think this can be fixed in the plugin if a new event was added to GCC just before laying out the struct: modified gcc/c/c-decl.cc @@ -9678,6 +9678,9 @@ finish_struct (location_t loc, tree t, tree fieldlist, tree attributes, TYPE_FIELDS (t) = fieldlist; + invoke_plugin_callbacks (PLUGIN_BEFORE_STRUCT_LAYOUT, t); + fieldlist = TYPE_FIELDS (t); + maybe_apply_pragma_scalar_storage_order (t); layout_type (t); I've modified the current Linux randomizer plugin to make use of this and it /seems/ to work but I didn't fully test it yet so I'm not sure. WDYT of the above?
Reopening per above for discussion. We've had some discussion off-bug about it as well.
Randomizing fields order is invalid thing to do in general. C++ committee even went out of its way to make a mention that it is invalid (there is a defect report asking about it). Also this is not security at all, this just makes things not reproducible at all and even if you have the same seed small changes could change things.
Hi Andrew, do you have a pointer to the committee recommendation or discussion, it would be helpful to understand the reasoning. thanks