Andy Whitcroft wrote:
It truly is not clear what "type" of thing an __asm__ is these days.
Cirtainly it seems we can use it as an attribute of a type:
register unsigned long __r16 __asm__("$16") = rtc_access->function;
and yet also in its more traditional
On Tue, Jan 29, 2008 at 05:17:28PM -0600, Timur Tabi wrote:
> checkpatch.pl thinks that __asm__ is a function name, so it complains about
> a space between the function name and a parenthesis when it sees
> "__asm__ ("mov ax,bx")".
>
> This change will also e
checkpatch.pl thinks that __asm__ is a function name, so it complains about
a space between the function name and a parenthesis when it sees
"__asm__ ("mov ax,bx")".
This change will also encourage developers to use '__asm__' instead of 'asm'.
Sig
On Mon, 2007-07-23 at 23:30 +0200, Andi Kleen wrote:
> > gcc also tries to count the number of instructions, to guess how large in
> > bytes the asm block is, as it could make a difference for near vs short
> > jumps, etc.
>
> Are you sure? I doubt it. It would need a full asm parser to do this
>
> gcc also tries to count the number of instructions, to guess how large in
> bytes the asm block is, as it could make a difference for near vs short
> jumps, etc.
Are you sure? I doubt it. It would need a full asm parser to do this
properly and then even it could be wrong
(e.g. when the section
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
> Trent Piepho wrote:
> > gcc also tries to count the number of instructions, to guess how large in
> > bytes the asm block is, as it could make a difference for near vs short
> > jumps, etc.
> >
>
> How does it do that? By looking for \n, ';', etc?
Trent Piepho wrote:
> gcc also tries to count the number of instructions, to guess how large in
> bytes the asm block is, as it could make a difference for near vs short
> jumps, etc.
>
How does it do that? By looking for \n, ';', etc?
J
-
To unsubscribe from this list: send the line "uns
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
> Satyam Sharma wrote:
> > The (3) as I had originally written / meant was that multiple
> > instructions in a volatile asm would not get _individually_
> > interspersed with the rest of the code i.e. be emitted out
> > _consecutively_. I don't think
Satyam Sharma wrote:
> The (3) as I had originally written / meant was that multiple
> instructions in a volatile asm would not get _individually_
> interspersed with the rest of the code i.e. be emitted out
> _consecutively_. I don't think we need any such guarantees for
> the non-atomic variants
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
> I'm not quite sure what your point is.
Could be a case of terminology confusion ...
> The paragraph you quoted is
> pretty explicit in saying that volatile doesn't prevent an "asm
> volatile" from being interspersed with other code, and the examp
Satyam Sharma wrote:
> Hi Jeremy,
>
>
> On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
>
>
>> Satyam Sharma wrote:
>>
>>> From: Satyam Sharma <[EMAIL PROTECTED]>
>>>
>>> [7/8] i386: bitops: Kill needless usage of __asm__
Hi Jeremy,
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
> Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
> >
> > Another oddity I noticed in this file. The sem
Hi,
On Mon, 23 Jul 2007, Andi Kleen wrote:
> On Monday 23 July 2007 18:06:03 Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
> >
> > Another oddity I noticed in t
Satyam Sharma wrote:
> From: Satyam Sharma <[EMAIL PROTECTED]>
>
> [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
>
> Another oddity I noticed in this file. The semantics of __volatile__
> when used to qualify inline __asm__ are that the compiler wil
BTW if you want to optimize inline asm code a bit -- find_first_bit /
find_first_zero_bit / for_each_cpu could really benefit from a optimized
version
for cpumask_t sized bitmaps. That would save a lot of cycles in some of the
hotter paths of the kernel like the scheduler.
-Andi
-
To unsubsc
On Monday 23 July 2007 18:06:03 Satyam Sharma wrote:
> From: Satyam Sharma <[EMAIL PROTECTED]>
>
> [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
>
> Another oddity I noticed in this file. The semantics of __volatile__
> when used to qualify inline __asm
From: Satyam Sharma <[EMAIL PROTECTED]>
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when used to qualify inline __asm__ are that the compiler will not
(1) elid, or, (2) reorder, or, (3) interspers
Mike Frysinger wrote:
> On Wednesday 20 June 2007, H. Peter Anvin wrote:
>> Andi Kleen wrote:
asm-i386/msr.h should not be exported to userspace at all, it contains
nothing but kernel-internal helpers.
>>> Actually rdtsc and rdtscll and potentially rdpmc which is in there can be
>>> very
On Wednesday 20 June 2007, H. Peter Anvin wrote:
> Andi Kleen wrote:
> >> asm-i386/msr.h should not be exported to userspace at all, it contains
> >> nothing but kernel-internal helpers.
> >
> > Actually rdtsc and rdtscll and potentially rdpmc which is in there can be
> > very useful in user space
Andi Kleen wrote:
>> asm-i386/msr.h should not be exported to userspace at all, it contains
>> nothing but kernel-internal helpers.
>
> Actually rdtsc and rdtscll and potentially rdpmc which is in there can be
> very
> useful in user space if you know what you're doing. Unfortunately a lot of
>
On Mon, Jun 18, 2007 at 09:00:09PM +0200, Sam Ravnborg wrote:
> Do you imply that if we see asm or __asm__ in user space headers we ougth
> to warn about it?
> Seems at least sensible to me but if we introduce such a check we should
> kill all offenders first - which Mike's
On Mon, Jun 18, 2007 at 07:34:50PM +0100, Christoph Hellwig wrote:
> On Sun, Jun 17, 2007 at 06:33:28PM -0400, Mike Frysinger wrote:
> > This changes asm() to __asm__() and volatile to __volatile__ so that these
> > headers can be used with gcc's -std=c99.
>
> We shoul
> asm-i386/msr.h should not be exported to userspace at all, it contains
> nothing but kernel-internal helpers.
Actually rdtsc and rdtscll and potentially rdpmc which is in there can be very
useful in user space if you know what you're doing. Unfortunately a lot of its
users don't,
but not havi
On Mon, Jun 18, 2007 at 07:34:50PM +0100, Christoph Hellwig wrote:
> On Sun, Jun 17, 2007 at 06:33:28PM -0400, Mike Frysinger wrote:
> > This changes asm() to __asm__() and volatile to __volatile__ so that these
> > headers can be used with gcc's -std=c99.
>
> We shoul
On Mon, Jun 18, 2007 at 02:19:10AM -0400, Mike Frysinger wrote:
> Since asm-ia64/gcc_intrin.h gets exported to userspace, we need to make sure
> to use __asm__() rather than asm() since the latter is not available when
> compiling with gcc with GNU extensions turned off (like -std=c9
On Mon, Jun 18, 2007 at 10:02:21AM -0400, Mike Frysinger wrote:
> > This is wrong for two reasons:
> >
> > - MSRs are not accessible in user space.
> > - .section .fixup is not applicable to user space.
> >
> > Anything MSR-related should be protected by __KERNEL__ instead.
> >
> > This NAK doesn't
On Sun, Jun 17, 2007 at 06:33:28PM -0400, Mike Frysinger wrote:
> This changes asm() to __asm__() and volatile to __volatile__ so that these
> headers can be used with gcc's -std=c99.
We should not allow inline assemly in the exported part of userspace headers
at all. These header
On Monday 18 June 2007, Christoph Hellwig wrote:
> On Mon, Jun 18, 2007 at 01:24:24AM +0200, Arnd Bergmann wrote:
> > On Monday 18 June 2007, Arjan van de Ven wrote:
> > > On Sun, 2007-06-17 at 18:33 -0400, Mike Frysinger wrote:
> > > > This changes asm() to __asm__(
On Mon, Jun 18, 2007 at 08:27:15AM -0600, Robert Hancock wrote:
> If we expect userspace apps to include them, then I would vote for no,
> not for anything outside of #ifdef __KERNEL__ in exported headers. Keep
> in mind also that C++ apps may need to include these as well and those
> extensions
On Mon, Jun 18, 2007 at 01:24:24AM +0200, Arnd Bergmann wrote:
> On Monday 18 June 2007, Arjan van de Ven wrote:
> >
> > On Sun, 2007-06-17 at 18:33 -0400, Mike Frysinger wrote:
> > > This changes asm() to __asm__() and volatile to __volatile__ so that these
> > &g
Robert Hancock wrote:
>
> If we expect userspace apps to include them, then I would vote for no,
> not for anything outside of #ifdef __KERNEL__ in exported headers. Keep
> in mind also that C++ apps may need to include these as well and those
> extensions don't always play well in C++ mode. (Last
David Woodhouse wrote:
On Mon, 2007-06-18 at 01:24 +0200, Arnd Bergmann wrote:
On Monday 18 June 2007, Arjan van de Ven wrote:
On Sun, 2007-06-17 at 18:33 -0400, Mike Frysinger wrote:
This changes asm() to __asm__() and volatile to __volatile__ so that these
headers can be used with gcc&#
On Monday 18 June 2007, H. Peter Anvin wrote:
> Mike Frysinger wrote:
> > Most of the macros in msr.h already use __asm__ and __volatile__, this
> > patch brings the rest into line. This is needed since these get exported
> > into userspace (need to use strict __asm__ vs
On Mon, 2007-06-18 at 01:24 +0200, Arnd Bergmann wrote:
> On Monday 18 June 2007, Arjan van de Ven wrote:
> >
> > On Sun, 2007-06-17 at 18:33 -0400, Mike Frysinger wrote:
> > > This changes asm() to __asm__() and volatile to __volatile__ so that these
> > > header
On Mon, Jun 18, 2007 at 10:15:18AM +0200, Martin Schwidefsky wrote:
> On Mon, 2007-06-18 at 09:36 +0200, Heiko Carstens wrote:
> > Hmm.. spka is a sort of priviledged instruction and shouldn't be
> > user space visible.
> > I will move it so it's under #ifdef __KERNEL__.
>
> Yes, I think this is b
On Mon, 2007-06-18 at 09:36 +0200, Heiko Carstens wrote:
> Hmm.. spka is a sort of priviledged instruction and shouldn't be
> user space visible.
> I will move it so it's under #ifdef __KERNEL__.
Yes, I think this is better. On a side node, why did we add psw_set_key
to ptrace.h? processor.h would
On Monday 18 June 2007, Sam Ravnborg wrote:
> On Sun, Jun 17, 2007 at 06:54:24PM -0400, Mike Frysinger wrote:
> > This updates scripts/hdrschecks.sh by grepping for asm() constructs and
> > rejecting them in favor of __asm__() in exported headers.
>
> I have a new version
On Sun, Jun 17, 2007 at 06:54:24PM -0400, Mike Frysinger wrote:
> This updates scripts/hdrschecks.sh by grepping for asm() constructs and
> rejecting them in favor of __asm__() in exported headers.
Hi Mike.
I have a new version of hdrcheck in works written in perl
and a bit faster too.
I h
Mike Frysinger wrote:
> Most of the macros in msr.h already use __asm__ and __volatile__, this patch
> brings the rest into line. This is needed since these get exported into
> userspace (need to use strict __asm__ vs asm when gcc compiles with GNU
> extensions turned off).
> ---
On Mon, Jun 18, 2007 at 02:23:06AM -0400, Mike Frysinger wrote:
> Since asm-s390/ptrace.h is exported to userspace, we need to make sure we use
> __asm__() rather than asm() as the latter is disabled when gcc compiles with
> GNU extensions turned off (like -std=c99).
>
> Sign
On 6/18/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Mon, 18 Jun 2007 01:17:46 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote:
> On Monday 18 June 2007, Andrew Morton wrote:
> > And does the kernel pass these checks?
>
> nope ... should i audit the arches before this gets merged ?
Yes please.
Since asm-s390/ptrace.h is exported to userspace, we need to make sure we use
__asm__() rather than asm() as the latter is disabled when gcc compiles with
GNU extensions turned off (like -std=c99).
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/include/asm-s390/ptra
Since asm-ia64/gcc_intrin.h gets exported to userspace, we need to make sure
to use __asm__() rather than asm() since the latter is not available when
compiling with gcc with GNU extensions turned off (like -std=c99).
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/inclu
Most of the macros in msr.h already use __asm__ and __volatile__, this patch
brings the rest into line. This is needed since these get exported into
userspace (need to use strict __asm__ vs asm when gcc compiles with GNU
extensions turned off).
Signed-off-by: Mike Frysinger <[EMAIL PROTEC
On Monday 18 June 2007, Andrew Morton wrote:
> Also, your changelog sucks:
>
> This updates scripts/hdrschecks.sh by grepping for asm() constructs and
> rejecting them in favor of __asm__() in exported headers.
>
> well OK. But for what reason? We can see a lot of pain in t
> This updates scripts/hdrschecks.sh by grepping for asm() constructs
> > > > and rejecting them in favor of __asm__() in exported headers.
> > >
> > > And does the kernel pass these checks?
> >
> > nope ... should i audit the arches before this gets merg
pping for asm() constructs and
> > > rejecting them in favor of __asm__() in exported headers.
> >
> > And does the kernel pass these checks?
>
> nope ... should i audit the arches before this gets merged ?
Yes please. I'd rather not break things in this fashion: it causes
On Monday 18 June 2007, Andrew Morton wrote:
> On Sun, 17 Jun 2007 18:54:24 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > This updates scripts/hdrschecks.sh by grepping for asm() constructs and
> > rejecting them in favor of __asm__() in exported headers.
>
> And
On Sun, 17 Jun 2007 18:54:24 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote:
> This updates scripts/hdrschecks.sh by grepping for asm() constructs and
> rejecting them in favor of __asm__() in exported headers.
And does the kernel pass these checks? Which architectures have been
On Sunday 17 June 2007, Arnd Bergmann wrote:
> On Monday 18 June 2007, Arjan van de Ven wrote:
> > On Sun, 2007-06-17 at 18:33 -0400, Mike Frysinger wrote:
> > > This changes asm() to __asm__() and volatile to __volatile__ so that
> > > these headers can be used with
On Monday 18 June 2007, Arjan van de Ven wrote:
>
> On Sun, 2007-06-17 at 18:33 -0400, Mike Frysinger wrote:
> > This changes asm() to __asm__() and volatile to __volatile__ so that these
> > headers can be used with gcc's -std=c99.
>
> hmm but the kernel doesn
On Sun, 2007-06-17 at 18:33 -0400, Mike Frysinger wrote:
> This changes asm() to __asm__() and volatile to __volatile__ so that these
> headers can be used with gcc's -std=c99.
hmm but the kernel doesn't use -std=c99...
-
To unsubscribe from this list: send the line "uns
This updates scripts/hdrschecks.sh by grepping for asm() constructs and
rejecting them in favor of __asm__() in exported headers.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/scripts/hdrcheck.sh b/scripts/hdrcheck.sh
index 3159858..33d17cc 100755
--- a/scripts/hdrch
This changes asm() to __asm__() and volatile to __volatile__ so that these
headers can be used with gcc's -std=c99.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/include/asm-arm/byteorder.h b/include/asm-arm/byteorder.h
index e6f7fcd..39105dc 100644
--- a/incl
Okay,
"current" is a macro on i386 that expands to "get_current()". This gets the
task_struct for the task currently running on the CPU executing the code.
It does this by masking out the bottom bits of its kernel stack pointer.
For example, assuming that some running process has the following
Blesson Paul Wrote:
> Thanks for the reply. I am sorry that I misspelled the
> line(__asm__()). It is from the get_current() function in
> asm-i386/current.h. But I am not clear what is the whole meaning of that
> line(__asm__(..)) in get_current(). I am doing
Hi David
Thanks for the reply. I am sorry that I misspelled the
line(__asm__()). It is from the get_current() function in
asm-i386/current.h. But I am not clear what is the whole meaning of that
line(__asm__(..)) in get_current(). I am doing a project in Linux related to
> __asm__("and 1 %%esp.%0; ":"=r" (current) : "0" (~8191UL));
This doesn't look right... Where did you get this from.
Taking the one in include/asm-i386/current.h as an example:
| __asm__(
This signifies a piece of inline assembly that the compiler
Hi
I am comfronting with a macro __asm__ . What is the meaning of
this. I cannot find the definition of this. I need the meaning of this line
__asm__("and 1 %%esp.%0; ":"=r" (current) : "0" (~8191UL));
This is defined inside
59 matches
Mail list logo
