[PATCH, Pointer Bounds Checker 20/x] Follow transparent alias chains

Jeff Law law@redhat.com
Tue Sep 23 21:24:00 GMT 2014


On 09/15/14 01:14, Ilya Enkovich wrote:
> Ping
>
> 2014-06-03 13:01 GMT+04:00 Richard Biener <richard.guenther@gmail.com>:
>> On Mon, Jun 2, 2014 at 5:15 PM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
>>> Hi,
>>>
>>> In the most case we follow transparent alias chains wne assemble names.  But in some cases it is not performed.  For instrumented functions it is critical and following patch fixes that.  It also adds a visibility inheritance for instrtumented functions.
>>
>> It feels like this should be handled by the symtab code nowadays ... Honza?
I don't see anything in cgraph that would handle this.  There's one bit 
of code that sets up these chains in symbol_table::compile.  That code 
hints that if we did the renaming in the gimple IL that the nonsense 
could go away, but for now we're stuck with the current chains.

So I'm going to work on the assumption that at least in the immediate 
term we're still walking the chains in varasm.  And in reality, all Ilya 
is doing is ensuring we're walking these chains in more cases where 
they're needed.




>>
>> Richard.
>>
>>> Bootstrapped and tested on linux-x86_64.
>>>
>>> Thanks,
>>> Ilya
>>> --
>>> gcc/
>>>
>>> 2014-06-02  Ilya Enkovich  <ilya.enkovich@intel.com>
>>>
>>>          * varasm.c: Include tree-chkp.h.
>>>          (ultimate_transparent_alias_target): Move up.
>>>          (make_decl_rtl): For instrumented function use
>>>          name of the original decl.
>>>          (assemble_start_function): Mark function as global
>>>          in case it is instrumentation clone of the global
>>>          function.
>>>          (do_assemble_alias): Follow transparent alias chain
>>>          for identifier.  Check if original alias is public.
>>>          (maybe_assemble_visibility): Use visibility of the
>>>          original function for instrumented version.
>>>          (default_unique_section): Likewise.
OK.

Jeff



More information about the Gcc-patches mailing list