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
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, solving this relocation requires information on the object
that holds th
19 matches
Mail list logo
