This is the mail archive of the gcc-patches@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: [LTO merge][6/15][RFA] Driver


> Thanks for the explanation. ÂThis may be a reasonable thing to do
> initially, but it doesn't seem to be a full solution, as there are other
> cases where symbol references could be introduced - built-in function
> optimizations transforming a call to one function to a call to another
> (likely in libc, which could be being linked statically), at least. ÂDo
> you have any way to eliminate that possibility?

I never found a case where we created calls to functions that were not
in libgcc. That is why the option has that name :-)

From the plugin point of view, libgcc is just something that gets
passed again to the liker. You can make the option generic (say
--rescan_objects) and pass more objects/libraries that should be
passed to the linker.

>ÂIf not, perhaps handling
> of .a libraries needs to handle more generally the possibility that the
> set of referenced symbols could increase, and you should have a PR open
> for replacing the libgcc-specific hack with something more general?

IMHO we should implement the more general solution only if a
problematic case is found. If you find a case, please open a PR.

> --
> Joseph S. Myers
> joseph@codesourcery.com


Cheers,
-- 
Rafael Ãvila de EspÃndola


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