On Jan 7, 2013, Richard Biener <richard.guent...@gmail.com> wrote: > On Sun, Jan 6, 2013 at 8:47 PM, Alexandre Oliva <aol...@redhat.com> wrote: >> On Jan 2, 2013, Richard Biener <richard.guent...@gmail.com> wrote: >> >>> On Sun, Dec 30, 2012 at 1:22 AM, Alexandre Oliva <aol...@redhat.com> wrote: >>>> On Dec 21, 2012, Richard Biener <richard.guent...@gmail.com> wrote: >>>> >>>>> On Fri, Dec 21, 2012 at 6:33 AM, Alexandre Oliva <aol...@redhat.com> >>>>> wrote: >>>>>> libmudflap emits a global initializer that registers memory ranges for >>>>>> global data symbols. However, even if IPA decides not to emit a symbol >>>>>> because it's unused, we'd still emit registration sequences for them in >>>>>> some cases, which, in the PR testcase, would result in TOC references to >>>>>> the undefined symbols. >>>> >>>>> Hmm, I think that at this point of the compilation you are looking for >>>>> TREE_ASM_WRITTEN instead. >>>> >>>> That doesn't work, several mudflap regressions show up because accesses >>>> to global library symbols that are accessed by template methods compiled >>>> with mudflap (say cout) are then verified but not registered. We have >>>> to register symbols that are not emitted but that referenced. >> >>> Ehm, how can something be not emitted but still referenced? You mean if >>> it's external? >> >> Yeah. >> >>> if (!TREE_ASM_WRITTEN (obj) || DECL_EXTERNAL (obj)) >> >>> instead? >> >> Then we're back to the original bug. >> >> How does the test above tell whether we're actually referencing the >> object? Only when we are do we want to register it with mudflap. If >> it's referenced and we don't register it, we get mudflap runtime errors. >> If it's not referenced but we register it, we get link-time errors if >> the symbol is one we'd have emitted if it was referenced.
> Then the bug is that we register something but do not actually tell the > middle-end that this is a reference. No, the bug is that we're registering something because at an earlier point (when we emitted checks) there were references to it. The references were all optimized away, we correctly decided (elsewhere) the object was not referenced, and we removed it from the symbol table, but mudflap still wants to register it because it pays no attention to that decision. This is the reason why I believe the patch I proposed initially is the correct fix. Now, can you please tell me why you believe this diagnosis is incorrect, or why the fix for the diagnosed problem is incorrect, to the point of proposing alternate (faulty) approaches? > I suppose instead of asking for TREE_ASM_WRITTEN you may want to look > at DECL_RTL (which should be set for all referenced decls, whether > external or not). I'm pretty sure the optimized-away objects that we do NOT want to register had DECL_RTL set, but I'm not exactly excited about double checking it without at least a hint of an explanation on what seems to be wrong with the proposed patch. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
