On Tue, Apr 1, 2014 at 2:35 AM, H. Peter Anvin wrote:
> Andi Kleen (24):
> Kbuild, lto: Drop .number postfixes in modpost
This generates a new warning with x86_64_defconfig atleast:
scripts/mod/modpost.c: In function 'remove_dot':
scripts/mod/modpost.c:1710:3: warning: ignoring return valu
On Wed, 02 Apr 2014 10:10:12 -0700
"H. Peter Anvin" wrote:
)
>
> Do you want to do the patch?
Sure, I could probably whip something up.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info
On 04/02/2014 05:33 AM, Steven Rostedt wrote:
> On Tue, 1 Apr 2014 17:35:05 -0700
>
> Heh, I know that not having the SYSCALL_DEFINEx() wrappers means that
> they wont be traced. I must have misunderstood Peter, as I thought he
> meant if we added SYSCALL_DEFINEx(), that they would break tracing.
On Tue, 1 Apr 2014 17:35:05 -0700
Linus Torvalds wrote:
> On Tue, Apr 1, 2014 at 5:01 PM, Steven Rostedt wrote:
> >
> > Why would they break tracing? I remember there was a issue with compat
> > calls, are these related to that?
>
> They "break" tracing by being invisible to syscall tracing. As
On Tue, 2014-04-01 at 16:17 -0700, Andi Kleen wrote:
> On Tue, Apr 01, 2014 at 10:49:51PM +0200, Paul Bolle wrote:
> > I can't find a Kconfig symbol LTO nor a preprocessor define for
> > CONFIG_LTO. (I only checked master of Linus's tree and linux-next.)
>
> The patch for LTO is not merged yet, th
On Tue, Apr 1, 2014 at 5:01 PM, Steven Rostedt wrote:
>
> Why would they break tracing? I remember there was a issue with compat
> calls, are these related to that?
They "break" tracing by being invisible to syscall tracing. As you
really should know ;)
The syscall tracing feature depends on the
On Tue, 01 Apr 2014 11:54:23 -0700
"H. Peter Anvin" wrote:
> On 03/31/2014 05:33 PM, Linus Torvalds wrote:
> >
> > I notice that there seems to be a handful of x86 system calls that
> > don't use the SYSCALL_DEFINEx() macros to define the system call, some
> > grepping finds at least ioperm(), m
On Tue, Apr 01, 2014 at 10:49:51PM +0200, Paul Bolle wrote:
> On Mon, 2014-03-31 at 14:05 -0700, H. Peter Anvin wrote:
> > --- a/include/linux/init.h
> > +++ b/include/linux/init.h
> > @@ -163,6 +163,23 @@ extern bool initcall_debug;
> >
> > #ifndef __ASSEMBLY__
> >
> > +#ifdef CONFIG_LTO
>
>
On Mon, 2014-03-31 at 14:05 -0700, H. Peter Anvin wrote:
> --- a/include/linux/init.h
> +++ b/include/linux/init.h
> @@ -163,6 +163,23 @@ extern bool initcall_debug;
>
> #ifndef __ASSEMBLY__
>
> +#ifdef CONFIG_LTO
I can't find a Kconfig symbol LTO nor a preprocessor define for
CONFIG_LTO. (I
Should be an easy fix through.
On April 1, 2014 12:15:05 PM PDT, Linus Torvalds
wrote:
>On Tue, Apr 1, 2014 at 11:54 AM, H. Peter Anvin
>wrote:
>>
>> Pretty much. If nothing else, it breaks tracing.
>
>Good point. And those [rt_]sigreturn() system calls might actually be
>something you want to
On Tue, Apr 1, 2014 at 11:54 AM, H. Peter Anvin wrote:
>
> Pretty much. If nothing else, it breaks tracing.
Good point. And those [rt_]sigreturn() system calls might actually be
something you want to see in traces.
Although clearly nobody has noticed the lack so far, so nobody must
have cared a
On 03/31/2014 05:33 PM, Linus Torvalds wrote:
>
> I notice that there seems to be a handful of x86 system calls that
> don't use the SYSCALL_DEFINEx() macros to define the system call, some
> grepping finds at least ioperm(), modify_ldt(), sigreturn() and
> rt_sigreturn(). There are probably other
On Mon, Mar 31, 2014 at 6:09 PM, Andi Kleen wrote:
>
> I think SYSCALL_DEFINE actually doesn't need it, as the syscall
> tables are visible in C. Only the syscall table itself
> needs to be visible.
Ahh, good point. The table used to be in asm for x86-32, but that got
fixed long ago so I guess th
On 03/31/2014 06:09 PM, Andi Kleen wrote:
>
> I think SYSCALL_DEFINE actually doesn't need it, as the syscall
> tables are visible in C. Only the syscall table itself
> needs to be visible.
>
I was just going to ask about that. That really means most asmlinkage
instances don't need it at all.
> - don't do the __visible as part of asmlinkage, because it really is
> conceptually wrong
Ok.
>
> - add the visible to the SYSCALL_DEFINEx() macros
I think SYSCALL_DEFINE actually doesn't need it, as the syscall
tables are visible in C. Only the syscall table itself
needs to be visible.
>
On Mon, Mar 31, 2014 at 5:17 PM, Linus Torvalds
wrote:
>
> So what I would propose is:
>
> - don't do the __visible as part of asmlinkage, because it really is
> conceptually wrong
>
> - add the visible to the SYSCALL_DEFINEx() macros
>
> and after that I strongly suspect that there will be only
On Mon, Mar 31, 2014 at 4:03 PM, Andi Kleen wrote:
>
> However with LTO pretty much all asmlinkages have to become
> visible, as they are used by assembler code and we need to
> tell that to the compiler, otherwise it'll optimize it away.
>
> So I abused asmlinkage for this.
I see why you did it,
> So I think that adding "visible" to asmlinkage is actively wrong and
> misguided. And the compiler even told you so, but somebody then chose
> to ignore the compiler telling them that they did stupid things.
Hi Linus,
In principle you're right. asmlinkage does not mean visible today.
However w
On Mon, Mar 31, 2014 at 2:05 PM, H. Peter Anvin wrote:
> diff --git a/include/linux/linkage.h b/include/linux/linkage.h
> index a6a42dd..34a513a 100644
> --- a/include/linux/linkage.h
> +++ b/include/linux/linkage.h
> @@ -12,9 +12,9 @@
> #endif
>
> #ifdef __cplusplus
> -#define CPP_ASMLINKAGE ex
Hi Linus,
More infrastructure work in preparation for link-time optimization
(LTO). Most of these changes is to make sure symbols accessed from
assembly code are properly marked as visible so the linker doesn't
remove them.
My understanding is that the changes to support LTO are still not
upstre
20 matches
Mail list logo
