On Wed, Feb 12, 2014 at 5:22 PM, Jan Hubicka hubi...@ucw.cz wrote:
On Wed, 12 Feb 2014, Richard Biener wrote:
What about instead of our current odd way of identifying LTO objects
simply add a special ELF note telling the linker the plugin to use?
.note._linker_plugin
On Tue, Feb 11, 2014 at 10:20 PM, Jan Hubicka hubi...@ucw.cz wrote:
Since both toolchains do the magic, binutils has no incentive to
create any automatic detection of objects.
It is mostly a historical decision. At the time the design was for the
plugin to be matched to the compiler, and so
What about instead of our current odd way of identifying LTO objects
simply add a special ELF note telling the linker the plugin to use?
.note._linker_plugin '/./libltoplugin.so'
that way the linker should try 1) loading that plugin, 2) register the
specific object with that plugin.
On Wed, 12 Feb 2014, Richard Biener wrote:
What about instead of our current odd way of identifying LTO objects
simply add a special ELF note telling the linker the plugin to use?
.note._linker_plugin '/./libltoplugin.so'
that way the linker should try 1) loading that plugin, 2)
On Wed, 12 Feb 2014, Richard Biener wrote:
What about instead of our current odd way of identifying LTO objects
simply add a special ELF note telling the linker the plugin to use?
.note._linker_plugin '/./libltoplugin.so'
that way the linker should try 1) loading that plugin,
Hi Jan,
I think this is a very good example where we could all collaborate
(including binutils).
I'll leave your reply intact, so that Chandler (CC'd) can get a bit
more context. I'm copying him because he (and I believe Diego) had
more contact with LTO than I had.
If I got it right, LTO today:
On Tuesday 11 February 2014 03:25 PM, Renato Golin wrote:
Hi Jan,
I think this is a very good example where we could all collaborate
(including binutils).
I'll leave your reply intact, so that Chandler (CC'd) can get a bit
more context. I'm copying him because he (and I believe Diego) had
On Tuesday 11 February 2014 03:25 PM, Renato Golin wrote:
Hi Jan,
I think this is a very good example where we could all collaborate
(including binutils).
I'll leave your reply intact, so that Chandler (CC'd) can get a bit
more context. I'm copying him because he (and I believe
On Tuesday 11 February 2014 09:30 PM, Jan Hubicka wrote:
On Tuesday 11 February 2014 03:25 PM, Renato Golin wrote:
Hi Jan,
I think this is a very good example where we could all collaborate
(including binutils).
I'll leave your reply intact, so that Chandler (CC'd) can get a bit
more
On 11 February 2014 16:00, Jan Hubicka hubi...@ucw.cz wrote:
I basically think that binutils should have a way for installed compiler to
register a plugin and load all plugins by default (or perhaps for performance
or upon detecking an compatible LTO object file in some way, perhaps also by
Now copying Rafael, which can give us some more insight on the LLVM LTO side.
cheers,
--renato
On 11 February 2014 09:55, Renato Golin renato.go...@linaro.org wrote:
Hi Jan,
I think this is a very good example where we could all collaborate
(including binutils).
I'll leave your reply
On 11 February 2014 12:28, Renato Golin renato.go...@linaro.org wrote:
Now copying Rafael, which can give us some more insight on the LLVM LTO side.
Thanks.
On 11 February 2014 09:55, Renato Golin renato.go...@linaro.org wrote:
Hi Jan,
I think this is a very good example where we could all
On 2014.02.11 at 13:02 -0500, Rafael Espíndola wrote:
On 11 February 2014 12:28, Renato Golin renato.go...@linaro.org wrote:
Now copying Rafael, which can give us some more insight on the LLVM LTO
side.
Thanks.
On 11 February 2014 09:55, Renato Golin renato.go...@linaro.org wrote:
On 2014.02.11 at 13:02 -0500, Rafael Espíndola wrote:
On 11 February 2014 12:28, Renato Golin renato.go...@linaro.org wrote:
Now copying Rafael, which can give us some more insight on the LLVM LTO
side.
Thanks.
On 11 February 2014 09:55, Renato Golin renato.go...@linaro.org
Since both toolchains do the magic, binutils has no incentive to
create any automatic detection of objects.
It is mostly a historical decision. At the time the design was for the
plugin to be matched to the compiler, and so the compiler could pass
that information down to the linker.
My reading of bfd/plugin.c is that it basically walks the directory and looks
for first plugin that returns OK for onload. (that is always the case for
GCC/LLVM plugins). So if I instlal GCC and llvm plugin there it will
depend who will end up being first and only that plugin will be used.
1. There IS an unnecessary fence between GCC and LLVM.
License arguments are one reason why we can't share code as easily as
we would like, but there is no argument against sharing ideas,
cross-reporting bugs, helping each other implement a better
compiler/linker/assembler/libraries just
Folks,
I'm about to do something I've been advised against, but since I
normally don't have good judgement, I'll risk it, because I think it's
worth it. I know some people here share my views and this is the
reason I'm writing this.
The problem
For a long time already I've been hearing on the
On Fri, 7 Feb 2014, Renato Golin wrote:
For a long time already I've been hearing on the LLVM list people
saying: oh, ld should not accept this deprecated instruction, but we
can't change that, that would be a good idea, but we need to talk to
the GCC guys first, and to be honest, nobody ever
On 7 February 2014 23:30, Joseph S. Myers jos...@codesourcery.com wrote:
I think there are other closely related issues, as GCC people try to work
around issues with glibc, or vice versa, rather than coordinating what
might be the best solution involving changes to both components,
Hi Joseph,
20 matches
Mail list logo
