This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: externally_visible and resoultion file



> -----Original Message-----
> From: Cary Coutant [mailto:ccoutant@google.com]
> Sent: 09 June 2010 18:43
> To: Richard Guenther
> Cc: Bingfeng Mei; Jan Hubicka; gcc@gcc.gnu.org
> Subject: Re: externally_visible and resoultion file
> 
> >> Yes, this is also what I saw without plugin. I just wonder why
> "vvvvv"
> >> is linked with plugin if resolution file is not used to eliminate
> need
> >> of externally_visible attribute here.
> >
> > Probably because of the same linker-plugin bug that causes bar
> > to be resolved.
> 
> Just to make sure I understand the problem:
> 
> - The IR file for a.c contains definitions for vvvvv and bar.
> - The linker identifies that both symbols are referenced from outside
> the LTO world (PREVAILING_DEF rather than PREVAILING_DEF_IRONLY), but
> gcc isn't (yet) reading that info from the resolution file.

> - WPA eliminates bar() and makes vvvvv static in the replacement object
> file.
> - There are still references to those symbols in b.o, which was
> compiled outside LTO.
> - The linker should be complaining about undefined symbols in both
> cases, but isn't (perhaps because it's still seeing defs left over
> from the IR files). The symbol bar has a value of 0, while the
> reference to vvvvv seems to have the right address.
> 
> Is that about right? What you're expecting is a link-time error
> reporting both bar and vvvvv as undefined, right?
> 
> -cary

Yes, I expect link-time errors of undefined reference for both
bar and vvvvvv. Instead, bar is linked to a bogus one (address 0)
and vvvvvv is linked correctly. 





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]