[Bug plugins/92217] New: compiler crash due to get_named_event_id not initializing extra reallocated memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92217 Bug ID: 92217 Summary: compiler crash due to get_named_event_id not initializing extra reallocated memory Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: pageexec at gmail dot com Target Milestone: --- When trying to use get_named_event_id/etc for sending events from a plugin, invoke_plugin_callbacks_full will likely segfault because XNEWVEC/XRESIZEVEC in get_named_event_id don't initialize the extra part of the new memory block nor does get_named_event_id memset it explicitly. Next, register_callback will then link the new callback_info to whatever random memory content is found at plugin_callbacks[event] and then invoke_plugin_callbacks_full will crash when it tries to walk there. This bug has been present since the beginning so I guess noone has ever tested or used this facility before but it'd still be nice to get it fixed as it simplifies certain inter-plugin communications a lot. Thanks, PaX Team
[Bug gcov-profile/92817] New: the prototype of the built-in __gcov_exit function is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92817
Bug ID: 92817
Summary: the prototype of the built-in __gcov_exit function is
wrong
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: pageexec at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
git commit db46bcd377f4b4a26b9807a7cb3565a161178660 (since gcc 7) introduced
the callout to "void __gcov_exit(void)" however its construction looks like
this:
build_gcov_exit_decl (void)
{
tree init_fn = build_function_type_list (void_type_node, void_type_node,
NULL);
instead it should be this:
build_gcov_exit_decl (void)
{
tree init_fn = build_function_type_list (void_type_node, NULL);
as it is, the builtin-in prototype does not match what one would define in
source code and this trips up type based control-flow integrity checks.
[Bug gcov-profile/92817] the prototype of the built-in __gcov_exit function is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92817 --- Comment #5 from PaX Team --- (In reply to Martin Liška from comment #2) > You are right, it's wrong. Can you please explain to me what control-flow > integrity check do you use? it's my own called RAP (Reuse Attack Protector, see https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf). a public version for linux (the kernel) is available in PaX and grsecurity though i think that older version won't find this problem as it didn't handle internal types like this at the time.
[Bug plugins/59335] Plugin doesn't build on trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335 PaX Team changed: What|Removed |Added CC||pageexec at gmail dot com --- Comment #2 from PaX Team --- there're some more missing headers for plugins on amd64 at least: gimplify.h tree-flow.h tree-flow-inline.h config/i386/x86-tune.def
[Bug plugins/59335] Plugin doesn't build on trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335 --- Comment #3 from PaX Team --- small correction: tree-flow.h and tree-flow-inline.h seem to be removed however here's an additional list of headers that i needed to copy over manually to get some plugins to compile: fold-const.h gimple-ssa.h tree-ssanames.h context.h print-tree.h gimple-iterator.h varasm.h
[Bug ipa/82256] [6/7/8 Regression] clones created by create_version_clone_with_body are not observable to insertion hooks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82256 --- Comment #4 from PaX Team --- any update on this? it seems that the window for fixing 5.x was missed but perhaps it's still not too late for the others, especially if they get updated for spectre anyway...
[Bug c/84052] Using Randomizing structure layout plugin in linux kernel compilation doesn't generate proper debuginfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84052 --- Comment #3 from PaX Team --- (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.
[Bug c/84052] Using Randomizing structure layout plugin in linux kernel compilation doesn't generate proper debuginfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84052 --- Comment #5 from PaX Team --- (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.
[Bug ipa/82256] [6/7 Regression] clones created by create_version_clone_with_body are not observable to insertion hooks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82256 --- Comment #7 from PaX Team --- (In reply to Jan Hubicka from comment #5) > I am going to test the patch against mainline and commit it. However about > backporting, can you produce some issue with this bug? well, the thing is that i ran across this while playing with the plugin API and noticed that my notification callbacks didn't see the expected cgraph nodes on certain gcc versions (v5+) which made me look into the cause and find the typo made during the refactoring. as for sideeffects, gcc itself is a user of these hooks (ipa-prop.c, ipa-pure-const.c and symbol-summary.h) so missing nodes there can probably have undesirable sideeffects but it's probably best to let gcc developers familiar with that code determine that. in any case, i think the regressive nature of this bug alone should warrant a backport to all affected versions...
[Bug plugins/61176] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176 --- Comment #21 from PaX Team --- (In reply to PaX Team from comment #20) > update for gcc-6: /gcc/params.list is also needed now as it gets > included by params.h. PR69758 fixes it.
[Bug plugins/69758] [6 Regression] Plugins can't include params.h (missing params.list)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69758 PaX Team changed: What|Removed |Added CC||pageexec at gmail dot com --- Comment #4 from PaX Team --- just for the record, this was also reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176#c20
[Bug ipa/82256] New: regression: clones created by create_version_clone_with_body are not observable to insertion hooks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82256 Bug ID: 82256 Summary: regression: clones created by create_version_clone_with_body are not observable to insertion hooks Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: pageexec at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- the following commit 35ee1c662b92e8c6475d4eab310bf33371708a28 Author: marxin Date: Mon Aug 25 13:01:47 2014 + IPA C++ refactoring 4/N introduced a presumably unintended change in cgraph_node::create_version_clone_with_body: @@ -970,14 +972,14 @@ cgraph_node::create_version_clone_with_body /* Update the call_expr on the edges to call the new version node. */ update_call_expr (new_version_node); - new_version_node->call_function_insertion_hooks (); + symtab->call_cgraph_insertion_hooks (this); return new_version_node; } notice how 'this' is passed to call_cgraph_insertion_hooks instead of the previously passed new_version_node. this makes new nodes unobservable to such hooks and also makes 'this' observed as many times as these clones are created, both broke existing behaviour i think. the correct change should be: symtab->call_cgraph_insertion_hooks (new_version_node); i hope this can be fixed in time for the last 5.x release (and of course also all the newer versions, master is affected).
[Bug ipa/82256] [5/6/7/8 Regression] clones created by create_version_clone_with_body are not observable to insertion hooks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82256 --- Comment #2 from PaX Team --- (In reply to Martin Liška from comment #1) > Hi. Sorry for the breakage. Are you planning to post patch for that? i wasn't going to, but here it is: diff --git a/gcc/cgraphclones.c b/gcc/cgraphclones.c index 93668ab99816..fa2e45226351 100644 --- a/gcc/cgraphclones.c +++ b/gcc/cgraphclones.c @@ -1039,7 +1039,7 @@ cgraph_node::create_version_clone_with_body /* Update the call_expr on the edges to call the new version node. */ update_call_expr (new_version_node); - symtab->call_cgraph_insertion_hooks (this); + symtab->call_cgraph_insertion_hooks (new_version_node); return new_version_node; } > I believe you'll be able to backport that. i already tested this locally but i'd much prefer this to be fixed in gcc proper since it affects gcc's own callbacks too.
[Bug plugins/59335] Plugin doesn't build on trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335 --- Comment #18 from PaX Team --- found another missing header not installed for plugins: stmt.h (seemingly it was split off from tree.h which has always been exported, so this probably counts as a regression).
[Bug plugins/59335] Plugin doesn't build on trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335 --- Comment #22 from PaX Team --- some notes: 1. there're *.def files as well needed for certain headers 2. there're target specific headers and .def files installed/needed from gcc/config/*/ as well 3. it's hard to tell a priori what one will need ;), but i'd say tree*.h, gimple*.h, *rtl*.h, targ*.h, expr.h, recog,h, regs.h, reload.h, ira.h, dwarf2asm.h, hosthooks.h, coverage.h, value-prof.h, alloc-pool.h, lto-streamer.h, diagnostic-color.h at least would be useful (and all their dependencies of course).
[Bug debug/61070] New: debug_bitmap writes to stdout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61070 Bug ID: 61070 Summary: debug_bitmap writes to stdout Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: pageexec at gmail dot com Unlike other debug_* functions, debug_bitmap doesn't write to stderr making it not too useful (and writing to stdout also clobbers the primary output of the compiler).
[Bug plugins/61176] [4.9/4.10 Regression] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176 PaX Team changed: What|Removed |Added CC||pageexec at gmail dot com --- Comment #8 from PaX Team --- I maintain a compatibility header for gcc plugins that also happens to include all the headers that we needed so far: https://www.grsecurity.net/~paxguy1/gcc-common.h (this copy may not always be up-to-date, the latest version is inside the PaX patch). As for include-what-you-use, I think it's not a viable model for plugins that want to support a range of gcc versions...
[Bug plugins/61311] New: missing LTO/WPA serialization API for use by regular IPA passes implemented in a plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61311 Bug ID: 61311 Summary: missing LTO/WPA serialization API for use by regular IPA passes implemented in a plugin Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: pageexec at gmail dot com I recently faced the problem of implementing the four summary read/write callbacks for an IPA pass in a plugin. It turned out that the high level APIs for creating the input/output streams (e.g., create_output_block) expect 'enum lto_section_type' (instead of, say, a string). Given that this enum obviously cannot be expanded without patching the compiler itself, using the serialization API from a plugin requires some code duplication to avoid calling lto_get_section_name() deep down and the manual construction of the ELF section name. Given that the enum isn't used for much else but to look up the basic section name in lto_section_name[] and some statistics gathering, I think its use for constructing the streams (and in particular the section name) should be deprecated and instead plugins (and even in-tree users) should just be able to provide their part of the section name as a simple string instead. The second problem is the usual case of missing headers, I had to manually install the following ones for gcc 4.9: gcc/lto-streamer.h gcc/gcov-io.h gcc/data-streamer.h gcc/lto-compress.h gcc/lto/lto.h /gcc/gcov-iov.h
[Bug other/61313] New: configure incorrectly strips $target_alias from PLUGIN_LD_SUFFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61313 Bug ID: 61313 Summary: configure incorrectly strips $target_alias from PLUGIN_LD_SUFFIX Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: pageexec at gmail dot com When gcc is configured using --with-plugin-ld=/some/path/x86_64-pc-linux-gnu-hjl-master/bin/ld the resulting ld path will be reduced to the incorrect /some/path/hjl-master/bin/ld (for a x86_64-pc-linux-gnu target). This change was introduced by git commit 61f41b94c58c64e7334d97df57d6467cb1c7b70e and is part of gcc 4.8+.
[Bug plugins/61176] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176 --- Comment #14 from PaX Team --- it seems that gcc/builtins.h doesn't get installed for plugins.
[Bug plugins/61176] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176 --- Comment #18 from PaX Team --- (In reply to Jakub Jelinek from comment #17) > Created attachment 35144 [details] > gcc5-pr61176.patch > > Patch to install all gcc/*.h and gcc/*.def headers, even when they aren't > listed in PLUGIN_HEADERS. thanks, this will be a big (future-proof) step towards writing plugins! on a related note, there's PR61311 where (among other issues) i list a few more missing headers needed for LTO. some would now be handled with the wildcard match however there's still a few missing: gcc/lto/lto.h /gcc/gcov-iov.h while lto/lto.h is probably easy to add, i'm not sure about the build-time generated one...
[Bug plugins/59335] Plugin doesn't build on trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335 --- Comment #6 from PaX Team --- i can confirm that only gcc/config/i386/stringop.def and gcc/config/i386/x86-tune.def seem to be missing on x86 targets.
[Bug plugins/59335] Plugin doesn't build on trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335 --- Comment #8 from PaX Team --- Uroš, i tried your patch and it didn't install those two files. on the other hand i found more missing headers: gcc/tree-phinodes.h gcc/stor-layout.h gcc/ssa-iterators.h
[Bug plugins/59335] Plugin doesn't build on trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335 --- Comment #10 from PaX Team --- please reopen, this bug is not fixed yet.
[Bug plugins/59335] Plugin doesn't build on trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335 --- Comment #12 from PaX Team --- two more headers not installed (even by older gcc versions so a backport to at least 4.8/4.7 would be nice) but they're needed for an rtl pass to be able to make use of the df info: df.h regset.h
[Bug plugins/59335] Plugin doesn't build on trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335 --- Comment #13 from PaX Team --- another missing include in trunk: tree-cfgcleanup.h (it seems that it was split from tree-flow.h which used to be installed for plugins for gcc 4.5-4.8).
[Bug plugins/59335] Plugin doesn't build on trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335 --- Comment #17 from PaX Team --- sure, thanks for fixing the already mentioned ones, i verified that all works fine for my plugins at least. as a related question, isn't there a better way than playing this whack-a-mole game with gcc headers vs. plugin headers? as i understand it, the testsuite doesn't simulate an installed environment for plugins but there has to be a way to automatically discover new headers+dependencies that should be exposed to plugins... PS: i can't reopen this one as i don't seem to have such rights but i'll comment anyway if i run across something. PS2: can the $(RESOURCE_H) hunk be backported to the still maintained versions at least?
[Bug lto/61313] configure incorrectly strips $target_alias from PLUGIN_LD_SUFFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61313 --- Comment #2 from PaX Team --- do you have a few examples of expected input/output path pairs perhaps?
[Bug c/59856] Support sparse-style context checking, used to validate locking correctness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856 --- Comment #5 from PaX Team --- (In reply to Josh Triplett from comment #4) > (In reply to Tom Tromey from comment #3) > (As a vaguely related aside, how does GCC disambiguate whether an attribute > preceding the function declaration or definition applies to the return type > or to the function? I really hope that doesn't depend on the specific > attribute.) AFAIK, you can't put an attribute on the return type, it'll be interpreted as a function attribute instead (and on definitions you can't place them after the function arguments). the only way to put attrs on the return type is via a typedef. > Could you represent __context__ as a new GCC builtin? Would that make this > any easier? it can be a builtin or just a regular function declaration, the latter is easy to create from a plugin too. > So, I suspect the unfortunate answer is that Linux would probably want to > ship the plugin as C/C++ and build it at build time if enabled. (Or we could > integrate this functionality into GCC itself.) since PaX already has a checker plugin i subscribed to this bug a while ago but completely forgot about it until now ;P. in any case, i've begun to work on this along a somewhat different angle: instead of adding completely new machinery to detect context imbalances i'd like to reuse existing gcc passes to compute this property, we'll see how it goes.
[Bug c/59856] Support sparse-style context checking, used to validate locking correctness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856 --- Comment #12 from PaX Team --- 1. there's a (linux) kernel-hardening effort of late that among others will try to upstream the PaX gcc plugin infrastructure along with some plugins, so the checker one could be added to that list (but it wasn't part of the initial plan). you should probably continue this thread on that list instead as i doubt many kernel devs follow the gcc bugzilla ;). 2. as for my idea, it's simple: track the context via an artificially injected local integer variable (one per context if you want context sensitivity) and initialize it to the 'in' attr parameter or 0 otherwise then adjust its value on function calls that affect it based on the callee's context attribute. at the end compare the variable against the 'out' attr parameter (or 0) and complain on a mismatch (in my proof-of-concept i just called builtin_trap on a mismatch). now where gcc comes in is that it'll do constant propagation, DCE, etc for free so the final check either gets removed by dead code elimination (the locking is correct) or we detected a locking problem and can even determine the bad path(s). using this simple method on Josh's test file there're no false positives or false negatives. i'll work it into something usable (actual reports instead of having to check for leftover builtin_traps) and release it in PaX then linux can pick it up when the time comes.
[Bug c/59856] Support sparse-style context checking, used to validate locking correctness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856 --- Comment #14 from PaX Team --- (In reply to Josh Triplett from comment #13) > That sounds really plausible to me. GCC's constant propagation seems likely > to do *at least* as well as Sparse does, if not better. (As long as you > have optimizations turned on, anyway.) note that optimizations are not actually necessary for the scheme to work, it just means that the check(s) will have to do more work as you'll get a phi and have to traverse back the data flow to see if any unexpected values can end up there (optimizations basically do this data flow tracking for free and result in dead code elimination thus making it easier on the checks). in fact i expect that this will already happen on real linux code so the plugin will have to handle this case anyway. > Note that in addition to complaining if *any* exit to the function doesn't > have the correct "out" value, you also need to complain if calls to > functions with the context attribute don't have the necessary "in" value. sure, it's easy enough to inject more checks than just at the function return sites, i just wanted to validate my idea first then do the make-it-usable part which includes increased coverage too. > You may want to make that a separate warning option, though, as that option > tends to force adding annotations to far more functions. actually one idea for the future is to extend the plugin to be IPA then LTO aware so that it can discover the acquire/release properties itself based on an initial set of 'seed' functions that have to be marked by hand (and which already are i guess, all the direct callers of __context__ basically). we have experience in this area with the size overflow and other plugins, so the infrastructure is there already (albeit the LTO part is held up by PR61311). > This approach won't necessarily provide the "different contexts for basic > block" warning that Sparse has, but I don't necessarily think we need that; can you give me an example of this? the thing is, my approach tracks the context with statement granularity so if you can tell the compiler where you expect specific states (such as the context attr on callees) checks can be inserted there easily, down to individual statements (say, the structure field accesses you mentioned).
[Bug plugins/61176] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176 --- Comment #20 from PaX Team --- update for gcc-6: /gcc/params.list is also needed now as it gets included by params.h.
[Bug c/59856] Support sparse-style context checking, used to validate locking correctness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856
--- Comment #17 from PaX Team ---
(In reply to Josh Triplett from comment #16)
> (In reply to PaX Team from comment #14)
> > can you give me an example of this?
>
> Sparse warns if you can reach the same basic block with different context
> values (for instance, with or without a lock held). That warning *may*
> indicate a problem, but it can also just indicate code too intricate for
> Sparse to understand.
i see, so this would basically trigger every time a lock is taken/released
based on a condition as in the example in comment #1? or is there some deeper
analysis done to avoid at least some false positives?
in any case, with my method this checking is pretty easy too since the SSA
representation ensures that we get a phi for the local context tracking
variable if different paths produce different values when a given basic block
is reached. it also seems that gcc can eliminate at least some trivial false
reports since none of your conditional locking examples produce a false
positive or negative (however i expect real linux code to do worse).
> (In reply to Tom Tromey from comment #15)
> > Anyway given that this is happening, I suggest closing this gcc bug.
>
> Have we completely ruled out the possibility of a native GCC implementation?
> This really doesn't seem specific to the Linux kernel in any way; it'd be
> nice if this could work in most programs. We could add annotations to
> pthread locking functions, and any program using locking would benefit.
i agree, this context attribute based invariant verification is very generic
and could be worked into a general gcc feature. the plugin approach is a good
way to prototype it and get it some real life use before it'd make into the
compiler.
speaking of generalization, the encoding of the lock expression (e.g., lock
ptr) will have to change as it really doesn't seem feasible to refer to
function arguments from an attribute. as long as we expect to feed the compiler
only manual annotations, the only thing that matters is that the lock
expression be something unique, so as a compromise i suggest to simply make it
a string constant, which would both preserve context for a human programmer and
be also easy for the compiler to derive a unique name from for the local
variable tracking the given context. i.e., instead of
__attribute__((context(lock_expr, in, out))) we'd have
__attribute__((context("lock_expr", in, out))) and ditto for calling
__context__().
[Bug c/59856] Support sparse-style context checking, used to validate locking correctness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856 --- Comment #19 from PaX Team --- (In reply to Josh Triplett from comment #18) > (In reply to PaX Team from comment #17) > > (In reply to Josh Triplett from comment #16) > > speaking of generalization, the encoding of the lock expression (e.g., lock > > ptr) will have to change as it really doesn't seem feasible to refer to > > function arguments from an attribute. > > Doesn't seem too unreasonable to handle, actually. When parsing an > attribute, refer back to the function arguments; the context expression must > either use those or globals. the problem is that gcc itself refuses to parse an expression that wants to refer to a function argument (global variables work fine). this is something that changed with gcc-5, previously such a reference would at least produce an identifier_node (basically just the name of the referenced parameter but without any reference to the parm_decl itself, so not too useful), now it's a compile error: error: 'p' undeclared here (not in a function) so getting this to work would require frontend patches at least (and is beyond what a plugin can do but see below for an idea). > That fails for a really common case that should generate a warning: > > spin_lock(&some_lock); > /* Piles of code */ > spin_unlock(&some_other_lock); hmmm, true, so some parsing is inavoidable. the stringification idea may still be viable however as the attribute parsing code runs as part of the frontend so technically it has access to the parsing machinery and could perhaps extract at least simple expressions (or just a function argument) from the string. i'll make some experiments and see if i can get back a reference to a parm_decl at least.
[Bug c++/63905] New: redundant fields left in gcc/cp/cp-tree.h:lang_decl_fn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63905 Bug ID: 63905 Summary: redundant fields left in gcc/cp/cp-tree.h:lang_decl_fn Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: pageexec at gmail dot com svn commit 201994 (git commit fc3dabd5) changed DECL_CONSTRUCTOR_P/DECL_DESTRUCTOR_P to use middle-end flags instead of frontend flags however it didn't remove the now obsolete (unused) c++ frontend flags constructor_attr and destructor_attr from lang_decl_fn. fixing this would also free up 2 bits where there's only one left now.
[Bug c/59850] Support sparse-style pointer address spaces (type attributes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #23 from PaX Team --- some data points based on my experience with the 'checker' gcc plugin in PaX: 1. the C address space infrastructure available since gcc 4.6 can be sort of coerced into implementing the __user/__kernel/etc address spaces and it works reasonably well (i'd say even better than sparse as it produces no false positives in my experience and caught real bugs such as CVE-2014-0038). 2. __force itself presents a problem as its semantics isn't well defined and only sparse knows how to model it. in gcc it cannot be an attribute as attributes apply to the outermost variable/etc, e.g., you can't use them on a pointee in a pointer context. what i did instead is that i introduced new address spaces (__force_user/__force_kernel so far, __rcu/__iomem/etc will need more of these) that replace the '__force something' combination with __force_something (yes, this needs patching on the kernel side, and i haven't done a thorough job of it but it works on my smaller configs at least). this way the hijacked targetm.addr_space.legitimate_address_p callback can be taught to allow/disallow the intended conversions. 3. designated_init is a tricky problem because by the time a plugin can examine variable initializers, gcc will have lost the information. however with a trick such unwanted initializers can instead be turned into a compile error (that existing gcc infrastructure can detect). you can find it in spender's randomize_layout plugin that's distributed in grsecurity. 4. as for maintaining a plugin for kernel and/or other use: inside the kernel it'll need some kbuild infrastructure (there's one in PaX already, though it's probably not 100% complete) and it's worked fine for our users for the past 3+ years now. for more general use distros can package up plugins as they'd do with any library (as plugins are really nothing more than that). note also that keeping a plugin in the kernel tree will raise license problems (gplv2 vs gplv3) but i guess the kernel list is the better forum for discussing that.
[Bug c/59856] Support sparse-style context checking, used to validate locking correctness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856 --- Comment #20 from PaX Team --- (In reply to Josh Triplett from comment #13) > Note that in addition to complaining if *any* exit to the function doesn't > have the correct "out" value, you also need to complain if calls to > functions with the context attribute don't have the necessary "in" value. i implemented this now but it generates a warning on good_lock3, good_unlock2 and good_if3 (since there're paths where the same lock is taken twice before we reach the end of the function where we'd know that the lock count imbalance is fine). how should these cases be handled?
[Bug lto/71920] New: request to backport commit trunk@234239 to gcc 4.9 and 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71920
Bug ID: 71920
Summary: request to backport commit trunk@234239 to gcc 4.9 and
5
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: pageexec at gmail dot com
Target Milestone: ---
i encountered a crash while building recent linux kernels (v4.5+) in LTO mode.
when i tracked down the root cause it turned out that the underlying bug had
already been fixed by the following commit on trunk (and gcc 6) therefore i'd
like to request that it be backported to the still maintained branches.
commit 523f8924db2793abae1b981137b42da8b6c54878
Author: rth
Date: Tue Mar 15 23:08:45 2016 +
Fix compiling large files
* line-map.c (new_linemap): Make alloc_size a size_t.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@234239
138bc75d-0d04-0410-961f-82ee72b054a4
diff --git a/libcpp/ChangeLog b/libcpp/ChangeLog
index a2cb02f68a56..89b582d75402 100644
--- a/libcpp/ChangeLog
+++ b/libcpp/ChangeLog
@@ -1,3 +1,7 @@
+2016-03-15 Richard Henderson
+
+ * line-map.c (new_linemap): Make alloc_size a size_t.
+
2016-03-14 Jason Merrill
* expr.c (cpp_classify_number): Hex floats are new in C++1z.
diff --git a/libcpp/line-map.c b/libcpp/line-map.c
index 1fb634af5bf3..80d4e6b83921 100644
--- a/libcpp/line-map.c
+++ b/libcpp/line-map.c
@@ -376,7 +376,7 @@ new_linemap (struct line_maps *set,
if (LINEMAPS_USED (set, macro_map_p) == LINEMAPS_ALLOCATED (set,
macro_map_p))
{
/* We ran out of allocated line maps. Let's allocate more. */
- unsigned alloc_size;
+ size_t alloc_size;
/* Cast away extern "C" from the type of xrealloc. */
line_map_realloc reallocator = (set->reallocator
[Bug go/104973] GCC 11.2.1 build failure with Go support (mv: cannot stat 'cpugen.o': No such file or directory)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104973 --- Comment #3 from PaX Team --- (In reply to Andrew Pinski from comment #1) > Can you attach what is inside cpugen.go? i'm one of the original bug reproducers, this is what i get here: work # find . -name cpugen.go -ls 29921892 4 -rw-r--r-- 1 root root 74 Mar 18 10:13 ./build/x86_64-pc-linux-gnu/libgo/cpugen.go 29922436 4 -rw-r--r-- 1 root root 74 Mar 18 10:13 ./build/x86_64-pc-linux-gnu/32/libgo/cpugen.go work # cat ./build/x86_64-pc-linux-gnu/libgo/cpugen.go package cpu const CacheLinePadSize = 64 const FunctionDescriptors = false work # cat ./build/x86_64-pc-linux-gnu/32/libgo/cpugen.go package cpu const CacheLinePadSize = 64 const FunctionDescriptors = false the relevant build log: libtool: compile: /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/build/./gcc/gccgo -B/tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -fchecking=1 -minline-all-stringops -O2 -g -m32 -I . -c -fgo-pkgpath=golang.org/x/sys/cpu /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/byteorder.go /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/cpu.go /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/cpu_gccgo_x86.go /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/cpu_linux_noinit.go /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/cpu_x86.go /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/hwcap_linux.go gcpugen.go -fPIC -o golang.org/x/sys/.libs/cpu.o libtool: compile: /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/build/./gcc/gccgo -B/tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -fchecking=1 -minline-all-stringops -O2 -g -m32 -I . -c -fgo-pkgpath=golang.org/x/sys/cpu /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/byteorder.go /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/cpu.go /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/cpu_gccgo_x86.go /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/cpu_linux_noinit.go /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/cpu_x86.go /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/hwcap_linux .go gcpugen.go -o golang.org/x/sys/cpu.o >/dev/null 2>&1 note that there's a -o output specified but it's for the 'wrong' file name. i've got these cpu.o files: work # find . -name cpu.o -ls 29922270 60 -rw-r--r-- 1 root root58160 Mar 18 10:13 ./build/x86_64-pc-linux-gnu/libgo/cpu.o 29923192 44 -rw-r--r-- 1 root root41656 Mar 18 10:13 ./build/x86_64-pc-linux-gnu/32/libgo/internal/cpu.o 29922867 44 -rw-r--r-- 1 root root43384 Mar 18 10:13 ./build/x86_64-pc-linux-gnu/32/libgo/internal/.libs/cpu.o 29927256 92 -rw-r--r-- 1 root root92688 Mar 18 10:15 ./build/x86_64-pc-linux-gnu/32/libgo/golang.org/x/sys/cpu.o 29927254 96 -rw-r--r-- 1 root root95608 Mar 18 10:15 ./build/x86_64-pc-linux-gnu/32/libgo/golang.org/x/sys/.libs/cpu.o would you like me to upload anything of the above or any other build files?
[Bug plugins/105171] gcc/toplev.c: `local_tick` can overflow and become -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171 --- Comment #6 from PaX Team --- (In reply to Andrew Pinski from comment #5) > > So that I can decide whether I am allowed to do things totally randomly > > or if I must follow some sort of seeded determinism. > > That is almost always the wrong approach really. > Just assume the seed it always set and then use the seed as given. Don't > ever do something non-determinstic if you can avoid it. GCC has changed > away from that years ago. 'almost always' is the keyword here as there are situations where 1. we want to introduce compile time randomness into the compilation, 2. use gcc's PRNG or something else. case in point, our structure layout randomization gcc plugin that is now even in upstream linux. the problem is the decision in requirement #2 as so called 'reproducible builds' won't work too well without knowing whether the user wanted to control gcc's PRNG via -frandom-seed. this decision should be made based upon 'local_tick' but due to its undersized nature (should be u64) it can lead to false decisions. that's the bug we're talking about, other uses may or may not suffer but at this point are irreleant really. > The coverage.cc is a non-issue as libgcov will do the right thing as > mentioned. you didn't mention the 'why'. the conditional expression can falsely execute the unlink even when the file's uniquely stamped but the seed just happened to be 0 or -1 due to the bug. if those seed values don't matter then the comment and the conditional are wrong.
[Bug plugins/105171] gcc/toplev.c: `local_tick` can overflow and become -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171 --- Comment #9 from PaX Team --- (In reply to Andrew Pinski from comment #7) > I think there might be a way to check if the option -frandom-seed was passed > and that might be a better option for your usage anyways. You should check > the options handling code. i had checked it before but the trace that -frandom-seed/set_random_seed() leave behind is a static variable (flag_random_seed), local_tick would be an indirect indicator were it not for this bug. the only other way i can see is the rather big hammer of having to reparse common_deferred_options or save_decoded_options as mentioned by Jakub (both are gcc 4.6+ only)...
[Bug plugins/105171] gcc/toplev.c: `local_tick` can overflow and become -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171 --- Comment #12 from PaX Team --- (In reply to Jakub Jelinek from comment #11) > I think kernel requires gcc >= 5.1 anyway. there's more than one kernel version in active use and under development/support, even by upstream, not to mention companies/communities. for example linux 4.14 builds with gcc 3.2+, linux 5.4 builds with gcc 4.6+, linux 5.10 builds with gcc 4.9+, you get the idea. obviously plugins compiling for older gcc will have to use some hack to handle the bug here but going forward it'd be nice to do something better.
[Bug plugins/105171] gcc/toplev.c: `local_tick` can overflow and become -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171 --- Comment #14 from PaX Team --- (In reply to Jakub Jelinek from comment #13) > As has been said, we can't retroactively change released compilers from the > last 2 decades. And going forward, I think walking the save_decoded_options > is just fine and reliable, other plugins use that too. nobody talked about fixing old compilers, it's about fixing this bug on trunk. seriously, this is a one-liner u32->u64 change (or the simplification in coverage_finish), is the bikeshed on irrelevant tangents in over a dozen comments worth it vs. just fixing it?
[Bug ipa/96503] attribute alloc_size effect lost after inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503
PaX Team changed:
What|Removed |Added
CC||pageexec at gmail dot com
--- Comment #2 from Siddhesh Poyarekar ---
(In reply to Kees Cook from comment #1)
> Created attachment 53643 [details]
> PoC showing unexpected __bdos results across inlines
>
> Fixing this is needed for the Linux kernel to do much useful with
> alloc_size. Most of the allocators are inline wrappers, for example.
For cases where the size doesn't really change across the inlines, it ought to
be sufficient to annotate the non-inlined implementation function, e.g. in case
of kvmalloc, annotate kvmalloc_node as __alloc_size(1).
For other cases it may be less trivial, e.g.:
/* Some padding the wrapper adds to the actual allocation. */
size_t metadata_size;
__attribute__ ((alloc_size (1))) void *alloc_wrapper (size_t sz)
{
return real_alloc (size + metadata_size);
}
extern void *real_alloc (size_t) __attribute__ ((alloc_size(1)));
here the compiler will end up seeing the padded size, which may not be correct.
To fix this we'll have to store the alloc_size info somewhere (ptr_info seems
to be aliasing-specific, so maybe a new member to tree_ssa_name) during
inlining and then teach the tree-object-size pass to access it.
[Bug tree-optimization/111070] [14 Regregression] ./gcc.target/tic6x/abi-align-1.c on x86_64 with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111070 PaX Team changed: What|Removed |Added CC||pageexec at gmail dot com --- Comment #8 from PaX Team --- can you please backport this to gcc 12 as well given that the original commit causing the breakage was also backported https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111039#c6?
[Bug plugins/117972] Problems with plugin/include/errors.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117972
--- Comment #3 from PaX Team ---
(In reply to Andrew Pinski from comment #1)
> headers=`echo $(sort $(PLUGIN_HEADERS)) $$(cd $(srcdir); echo *.h
> *.def) | tr ' ' '\012' | sort -u`; \
>
> Which was done in r5-7988-gb626318e125111 . Basically We install all
> *.{h,def} files.
interesting, for some reason this doesn't pick up gcc/lto/lto.h .
