On Fri, Oct 20, 2017 at 03:44:12PM +0200, Torsten Duwe wrote:
> On Fri, Oct 20, 2017 at 08:24:32AM -0500, Josh Poimboeuf wrote:
> > On Fri, Oct 20, 2017 at 02:44:32PM +0200, Torsten Duwe wrote:
> > > I have a bad feeling about the IPA stuff in general. An obj-based approach
> > > is cool in a way t
On Fri, Oct 20, 2017 at 08:24:32AM -0500, Josh Poimboeuf wrote:
> On Fri, Oct 20, 2017 at 02:44:32PM +0200, Torsten Duwe wrote:
> > On Thu, Oct 19, 2017 at 06:00:54PM +0200, Miroslav Benes wrote:
> > > On Thu, 19 Oct 2017, Josh Poimboeuf wrote:
> > > >
> > > > Sounds nice, though I wonder what the
> > For -fpatchable-function-entries I switched
> > off IPA-RA, as especially on RISC there's _nothing_ you can do between
> > functions without at least one scratch reg. But for live patching, I'd like
> > the kernel to be compiled in the first place with 100% ABI adherence, IOW
> > all IPA optim
On Fri, Oct 20, 2017 at 02:44:32PM +0200, Torsten Duwe wrote:
> On Thu, Oct 19, 2017 at 06:00:54PM +0200, Miroslav Benes wrote:
> > On Thu, 19 Oct 2017, Josh Poimboeuf wrote:
> > >
> > > Sounds nice, though I wonder what the obstacles are?
> >
> > Those GCC optimizations you mentioned below and w
On Thu, Oct 19, 2017 at 06:00:54PM +0200, Miroslav Benes wrote:
> On Thu, 19 Oct 2017, Josh Poimboeuf wrote:
> >
> > Sounds nice, though I wonder what the obstacles are?
>
> Those GCC optimizations you mentioned below and which I didn't connect to
> klp-convert itself.
I have a bad feeling abou
On Fri, Oct 20, 2017 at 10:51:40AM +0200, Miroslav Benes wrote:
> > But with klp-convert, there's no such documentation, because there's no
> > safe way to use it without other supplementary tooling which doesn't
> > exist.
>
> True.
>
> I don't know if I mentioned it before. There is -fdump-ipa-
On Thu, 19 Oct 2017, Josh Poimboeuf wrote:
> On Thu, Oct 19, 2017 at 06:00:54PM +0200, Miroslav Benes wrote:
> > On Thu, 19 Oct 2017, Josh Poimboeuf wrote:
> > > My main objection to merging klp-convert in its current state is that
> > > it's not useful by itself. In fact, it's actively dangerous
On Thu, Oct 19, 2017 at 06:00:54PM +0200, Miroslav Benes wrote:
> On Thu, 19 Oct 2017, Josh Poimboeuf wrote:
> > My main objection to merging klp-convert in its current state is that
> > it's not useful by itself. In fact, it's actively dangerous if people
> > assume that because it's in-tree, it'
On Thu, 19 Oct 2017, Josh Poimboeuf wrote:
> On Thu, Oct 19, 2017 at 04:27:31PM +0200, Miroslav Benes wrote:
> > On Thu, 19 Oct 2017, Josh Poimboeuf wrote:
> > > > I think that klp-convert can work with both. Even with non-source-based
> > > > solution you need something to generate those relocat
On Thu, Oct 19, 2017 at 04:27:31PM +0200, Miroslav Benes wrote:
> On Thu, 19 Oct 2017, Josh Poimboeuf wrote:
> > > I think that klp-convert can work with both. Even with non-source-based
> > > solution you need something to generate those relocation records. I
> > > consider klp-convert as a part
On Thu, 19 Oct 2017, Josh Poimboeuf wrote:
> On Thu, Oct 19, 2017 at 03:24:51PM +0200, Miroslav Benes wrote:
> > On Thu, 19 Oct 2017, Josh Poimboeuf wrote:
> >
> > > On Wed, Oct 11, 2017 at 09:42:09AM -0300, Joao Moreira wrote:
> > > > > Sounds good! For klp-convert to be successful, we really n
On Thu, Oct 19, 2017 at 03:24:51PM +0200, Miroslav Benes wrote:
> On Thu, 19 Oct 2017, Josh Poimboeuf wrote:
>
> > On Wed, Oct 11, 2017 at 09:42:09AM -0300, Joao Moreira wrote:
> > > > Sounds good! For klp-convert to be successful, we really need a
> > > > strategy for dealing with such optimizat
On Thu, 19 Oct 2017, Josh Poimboeuf wrote:
> On Wed, Oct 11, 2017 at 09:42:09AM -0300, Joao Moreira wrote:
> > > Sounds good! For klp-convert to be successful, we really need a
> > > strategy for dealing with such optimizations. I'm thinking that a
> > > '-fpreserve-function-abi' flag would be t
On Wed, Oct 11, 2017 at 09:42:09AM -0300, Joao Moreira wrote:
> > Sounds good! For klp-convert to be successful, we really need a
> > strategy for dealing with such optimizations. I'm thinking that a
> > '-fpreserve-function-abi' flag would be the cleanest way to handle it.
> >
> > If we don't h
On 10/10/2017 11:46 PM, Josh Poimboeuf wrote:
On Tue, Oct 10, 2017 at 04:17:10PM +0200, Miroslav Benes wrote:
On Wed, 30 Aug 2017, Josh Poimboeuf wrote:
On Tue, Aug 29, 2017 at 04:01:32PM -0300, Joao Moreira wrote:
Livepatches may use symbols which are not contained in its own scope,
and, b
On Tue, Oct 10, 2017 at 04:17:10PM +0200, Miroslav Benes wrote:
> On Wed, 30 Aug 2017, Josh Poimboeuf wrote:
>
> > On Tue, Aug 29, 2017 at 04:01:32PM -0300, Joao Moreira wrote:
> > > Livepatches may use symbols which are not contained in its own scope,
> > > and, because of that, may end up compil
On Wed, 30 Aug 2017, Josh Poimboeuf wrote:
> On Tue, Aug 29, 2017 at 04:01:32PM -0300, Joao Moreira wrote:
> > Livepatches may use symbols which are not contained in its own scope,
> > and, because of that, may end up compiled with relocations that will
> > only be resolved during module load. Yet
On Tue, Aug 29, 2017 at 04:01:32PM -0300, Joao Moreira wrote:
> Livepatches may use symbols which are not contained in its own scope,
> and, because of that, may end up compiled with relocations that will
> only be resolved during module load. Yet, when the referenced symbols are
> not exported, so
18 matches
Mail list logo
