On Mon, Feb 18, 2019 at 11:32 PM Borislav Petkov wrote:
>
> On Mon, Feb 18, 2019 at 06:10:57PM +0900, Masahiro Yamada wrote:
> > Could you send v2 as I suggested?
> > Your commit log describes your motivation perfectly.
> >
> > (I lost the applicable patch because
> > I just modified the code loca
On Mon, Feb 18, 2019 at 06:10:57PM +0900, Masahiro Yamada wrote:
> Could you send v2 as I suggested?
> Your commit log describes your motivation perfectly.
>
> (I lost the applicable patch because
> I just modified the code locally and pasted it
> into the previous email.)
Sure, here it is.
Thx.
Borislav,
On Mon, Feb 18, 2019 at 5:30 PM Borislav Petkov wrote:
>
> On Sun, Feb 10, 2019 at 01:39:23PM +0100, Borislav Petkov wrote:
> > Please attach the diff or send it from another mail server.
>
> So you couldn't be bothered to send me an applicable version so I went
> and typed it in by ha
On Sun, Feb 10, 2019 at 01:39:23PM +0100, Borislav Petkov wrote:
> Please attach the diff or send it from another mail server.
So you couldn't be bothered to send me an applicable version so I went
and typed it in by hand. Thanks. ;-\
Anyway, this variant works too, pls queue it.
Acked-by: Boris
On Sun, Feb 10, 2019 at 03:51:01PM +0900, Masahiro Yamada wrote:
> I am still wondering,
> but if this is really worth doing in upstream code,
Yes, it is very worth doing it:
make .s
is one of the basic steps one does when trying to pinpoint the Code:
line in a splat back to the code gcc generat
On Wed, Feb 6, 2019 at 7:49 PM Borislav Petkov wrote:
>
> On Sat, Feb 02, 2019 at 03:42:27PM +0100, Borislav Petkov wrote:
> > On Sat, Feb 02, 2019 at 10:48:00PM +0900, Masahiro Yamada wrote:
> > > '?=' is the same as '=' here.
> >
> > Sure but if the slowdown disappears, then make does something
On Sat, Feb 02, 2019 at 03:42:27PM +0100, Borislav Petkov wrote:
> On Sat, Feb 02, 2019 at 10:48:00PM +0900, Masahiro Yamada wrote:
> > '?=' is the same as '=' here.
>
> Sure but if the slowdown disappears, then make does something else for
> '?=' apparently vs for '='.
Ok, let me ask a different
On Sat, Feb 02, 2019 at 10:48:00PM +0900, Masahiro Yamada wrote:
> '?=' is the same as '=' here.
Sure but if the slowdown disappears, then make does something else for
'?=' apparently vs for '='.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Sat, Feb 2, 2019 at 12:12 AM Borislav Petkov wrote:
>
> On Fri, Feb 01, 2019 at 08:58:13PM +0900, Masahiro Yamada wrote:
> > Variables assigned with ':=' are evaluated just on parsing Makefile.
> >
> > The scripts/Makefile.build is parsed over and over again,
> > so the compiler is invoked hund
On Fri, Feb 01, 2019 at 08:58:13PM +0900, Masahiro Yamada wrote:
> Variables assigned with ':=' are evaluated just on parsing Makefile.
>
> The scripts/Makefile.build is parsed over and over again,
> so the compiler is invoked hundreds times to test these four options
> even when you are not actua
On Fri, Feb 1, 2019 at 7:38 PM Borislav Petkov wrote:
>
> On Fri, Feb 01, 2019 at 11:30:38AM +0100, Borislav Petkov wrote:
> > This can't be a full kernel build.
>
> So I did this:
>
> $(obj)/%.s: $(src)/%.c FORCE
> @echo "HERE\n"
> $(call if_changed_dep,cc_s_c)
>
> and did a full
On Fri, Feb 1, 2019 at 7:25 PM Borislav Petkov wrote:
>
> On Fri, Feb 01, 2019 at 07:09:36PM +0900, Masahiro Yamada wrote:
> > Why should the normal build affected by the debugging aid?
>
> Hmm, ok, so then that target really is being used during the normal
> build. I don't know why yet so I'll ha
On Fri, Feb 1, 2019 at 7:32 PM Borislav Petkov wrote:
>
> On Fri, Feb 01, 2019 at 07:09:36PM +0900, Masahiro Yamada wrote:
> > I provide the result of "perf stat" of the incremental build for you.
>
> One more question: what exactly is that "incremental build" you're
> measuring with?
I meant "m
On Fri, Feb 01, 2019 at 11:30:38AM +0100, Borislav Petkov wrote:
> This can't be a full kernel build.
So I did this:
$(obj)/%.s: $(src)/%.c FORCE
@echo "HERE\n"
$(call if_changed_dep,cc_s_c)
and did a full kernel build with my .config. I got exactly *three*
"HERE"s in the build l
On Fri, Feb 01, 2019 at 07:09:36PM +0900, Masahiro Yamada wrote:
> I provide the result of "perf stat" of the incremental build for you.
One more question: what exactly is that "incremental build" you're
measuring with?
Exact command line please.
> Without your patch:
>
>
> Performance counte
On Fri, Feb 01, 2019 at 07:09:36PM +0900, Masahiro Yamada wrote:
> Why should the normal build affected by the debugging aid?
Hmm, ok, so then that target really is being used during the normal
build. I don't know why yet so I'll have to do some more staring.
> One more thing, you did not answer
On Fri, Feb 1, 2019 at 6:50 PM Borislav Petkov wrote:
>
> On Fri, Feb 01, 2019 at 12:06:13PM +0900, Masahiro Yamada wrote:
> > This would make the build speed slower
> > because the compiler is invoked to check those flags in every directory.
> >
> > I tested this patch with x86_64_defconfig and G
On Fri, Feb 01, 2019 at 12:06:13PM +0900, Masahiro Yamada wrote:
> This would make the build speed slower
> because the compiler is invoked to check those flags in every directory.
>
> I tested this patch with x86_64_defconfig and GCC 8.2
> (on ubuntu 18.10 in docker)
> but I saw no effect of this
On Thu, Jan 31, 2019 at 8:58 PM Borislav Petkov wrote:
>
> Ping?
>
> On Mon, Jan 21, 2019 at 10:53:38AM +0100, Borislav Petkov wrote:
> > From: Borislav Petkov
> >
> > Modern gcc adds view assignments, reset assertion checking in .loc
> > directives and a couple more additional debug markers, whi
Ping?
On Mon, Jan 21, 2019 at 10:53:38AM +0100, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Modern gcc adds view assignments, reset assertion checking in .loc
> directives and a couple more additional debug markers, which clutters
> the asm output unnecessarily:
>
> For example:
>
> b
20 matches
Mail list logo
