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
19 matches
Mail list logo
