[PATCH] Partially revert patch that encloses asm-offset.h numbers in brackets

[PATCH] Partially revert patch that encloses asm-offset.h numbers in brackets

[David Howells]

Partially revert patch:

	commit 3234282f33b29d349bcada40204fc7c8fda7fe72
	Author: Jan Beulich <JBeulich@novell.com>
	Date:   Tue Oct 19 14:52:26 2010 +0100
	x86, asm: Fix CFI macro invocations to deal with shortcomings in gas

This breaks MN10300 arch as this changes many instances of instructions
similar to the following:

	MOV	number,D0

which represents an immediate value load into:

	MOV	(number),D0

which the assembler then interprets as a load from absolute address.

arch/mn10300/kernel/entry.S:64: Error: Invalid opcode/operands
arch/mn10300/kernel/entry.S:65: Error: junk at end of line, first unrecognized character is `0'
arch/mn10300/kernel/entry.S:74: Error: Invalid opcode/operands
arch/mn10300/kernel/entry.S:74: Error: junk at end of line, first unrecognized character is `1'
arch/mn10300/kernel/entry.S:75: Error: Invalid opcode/operands
arch/mn10300/kernel/entry.S:76: Error: junk at end of line, first unrecognized character is `0'

cc: Jan Beulich <jbeulich@novell.com>
cc: Alexander van Heukelum <heukelum@fastmail.fm>
cc: H. Peter Anvin <hpa@linux.intel.com>
cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: David Howells <dhowells@redhat.com>
---

 Kbuild |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


diff --git a/Kbuild b/Kbuild
index 431f7ca..b00037a 100644
--- a/Kbuild
+++ b/Kbuild
@@ -53,7 +53,7 @@ targets += arch/$(SRCARCH)/kernel/asm-offsets.s
 # Default sed regexp - multiline due to syntax constraints
 define sed-y
 	"/^->/{s:->#\(.*\):/* \1 */:; \
-	s:^->\([^ ]*\) [\$$#]*\([-0-9]*\) \(.*\):#define \1 (\2) /* \3 */:; \
+	s:^->\([^ ]*\) [\$$#]*\([-0-9]*\) \(.*\):#define \1 \2 /* \3 */:; \
 	s:^->\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; \
 	s:->::; p;}"
 endef

Re: [PATCH] Partially revert patch that encloses asm-offset.h numbers in brackets

[Jan Beulich]

>>> On 25.10.10 at 16:02, David Howells <dhowells@redhat.com> wrote:
> Partially revert patch:
> 
> 	commit 3234282f33b29d349bcada40204fc7c8fda7fe72
> 	Author: Jan Beulich <JBeulich@novell.com>
> 	Date:   Tue Oct 19 14:52:26 2010 +0100
> 	x86, asm: Fix CFI macro invocations to deal with shortcomings in gas

No, that's not going to work for x86. You're removing the parentheses
again, which were added intentionally.

> This breaks MN10300 arch as this changes many instances of instructions
> similar to the following:
> 
> 	MOV	number,D0
> 
> which represents an immediate value load into:
> 
> 	MOV	(number),D0
> 
> which the assembler then interprets as a load from absolute address.
> 
> arch/mn10300/kernel/entry.S:64: Error: Invalid opcode/operands
> arch/mn10300/kernel/entry.S:65: Error: junk at end of line, first 
> unrecognized character is `0'
> arch/mn10300/kernel/entry.S:74: Error: Invalid opcode/operands
> arch/mn10300/kernel/entry.S:74: Error: junk at end of line, first 
> unrecognized character is `1'
> arch/mn10300/kernel/entry.S:75: Error: Invalid opcode/operands
> arch/mn10300/kernel/entry.S:76: Error: junk at end of line, first 
> unrecognized character is `0'

Isn't this a gas bug then? Anywhere you use a plain number you
should also be permitted to use an expression.

> cc: Jan Beulich <jbeulich@novell.com>
> cc: Alexander van Heukelum <heukelum@fastmail.fm>
> cc: H. Peter Anvin <hpa@linux.intel.com>
> cc: Ingo Molnar <mingo@elte.hu>
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
> 
>  Kbuild |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> 
> diff --git a/Kbuild b/Kbuild
> index 431f7ca..b00037a 100644
> --- a/Kbuild
> +++ b/Kbuild
> @@ -53,7 +53,7 @@ targets += arch/$(SRCARCH)/kernel/asm-offsets.s
>  # Default sed regexp - multiline due to syntax constraints
>  define sed-y
>  	"/^->/{s:->#\(.*\):/* \1 */:; \
> -	s:^->\([^ ]*\) [\$$#]*\([-0-9]*\) \(.*\):#define \1 (\2) /* \3 */:; \
> +	s:^->\([^ ]*\) [\$$#]*\([-0-9]*\) \(.*\):#define \1 \2 /* \3 */:; \

This basically gets us back to the way things were before, thus
reverting to the state we had before the patch that changed this.

>  	s:^->\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; \
>  	s:->::; p;}"
>  endef

Jan

Re: [PATCH] Partially revert patch that encloses asm-offset.h numbers in brackets

[Ingo Molnar]

* Jan Beulich <JBeulich@novell.com> wrote:

> >>> On 25.10.10 at 16:02, David Howells <dhowells@redhat.com> wrote:
> > Partially revert patch:
> > 
> > 	commit 3234282f33b29d349bcada40204fc7c8fda7fe72
> > 	Author: Jan Beulich <JBeulich@novell.com>
> > 	Date:   Tue Oct 19 14:52:26 2010 +0100
> > 	x86, asm: Fix CFI macro invocations to deal with shortcomings in gas
> 
> No, that's not going to work for x86. You're removing the parentheses again, which 
> were added intentionally.

But that's not a valid argument - MN10300 worked before and we broke it => that's a 
regression.

> > This breaks MN10300 arch as this changes many instances of instructions similar 
> > to the following:
> > 
> > 	MOV	number,D0
> > 
> > which represents an immediate value load into:
> > 
> > 	MOV	(number),D0
> > 
> > which the assembler then interprets as a load from absolute address.
> > 
> > arch/mn10300/kernel/entry.S:64: Error: Invalid opcode/operands
> > arch/mn10300/kernel/entry.S:65: Error: junk at end of line, first 
> > unrecognized character is `0'
> > arch/mn10300/kernel/entry.S:74: Error: Invalid opcode/operands
> > arch/mn10300/kernel/entry.S:74: Error: junk at end of line, first 
> > unrecognized character is `1'
> > arch/mn10300/kernel/entry.S:75: Error: Invalid opcode/operands
> > arch/mn10300/kernel/entry.S:76: Error: junk at end of line, first 
> > unrecognized character is `0'
> 
> Isn't this a gas bug then? Anywhere you use a plain number you should also be 
> permitted to use an expression.

This argument is not valid either - we added this change to fix a GAS bug to begin 
with ...

> >  	"/^->/{s:->#\(.*\):/* \1 */:; \
> > -	s:^->\([^ ]*\) [\$$#]*\([-0-9]*\) \(.*\):#define \1 (\2) /* \3 */:; \
> > +	s:^->\([^ ]*\) [\$$#]*\([-0-9]*\) \(.*\):#define \1 \2 /* \3 */:; \
> 
> This basically gets us back to the way things were before, thus
> reverting to the state we had before the patch that changed this.

Correct - we should apply David's partial revert and then we'll need to solve our 
x86 quirk differently: for example by using a x86 and broken-GAS specific quirk.

Thanks,

	Ingo

Re: [PATCH] Partially revert patch that encloses asm-offset.h numbers in brackets

[David Howells]

Jan Beulich <JBeulich@novell.com> wrote:

> Isn't this a gas bug then? Anywhere you use a plain number you
> should also be permitted to use an expression.

Whoever defined the gas assembly syntax for binutils specified that (N) as an
operand defines an absolute address and N defines an immediate value.

However, prefixing an expression with a unary plus works for me, so adding
this into my patch:

-	s:^->\([^ ]*\) [\$$#]*\([-0-9]*\) \(.*\):#define \1 \2 /* \3 */:; \
+	s:^->\([^ ]*\) [\$$#]*\([-0-9]*\) \(.*\):#define \1 +(\2) /* \3 */:; \

Does that work for you?

David

Re: [PATCH] Partially revert patch that encloses asm-offset.h numbers in brackets

[Jan Beulich]

>>> On 25.10.10 at 16:54, David Howells <dhowells@redhat.com> wrote:
> Jan Beulich <JBeulich@novell.com> wrote:
> 
>> Isn't this a gas bug then? Anywhere you use a plain number you
>> should also be permitted to use an expression.
> 
> Whoever defined the gas assembly syntax for binutils specified that (N) as 
> an
> operand defines an absolute address and N defines an immediate value.
> 
> However, prefixing an expression with a unary plus works for me, so adding
> this into my patch:
> 
> -	s:^->\([^ ]*\) [\$$#]*\([-0-9]*\) \(.*\):#define \1 \2 /* \3 */:; \
> +	s:^->\([^ ]*\) [\$$#]*\([-0-9]*\) \(.*\):#define \1 +(\2) /* \3 */:; \
> 
> Does that work for you?

Alexander, you seem to be having access to a worst case system -
could you give this a try?

Thanks, Jan

Re: [PATCH] Partially revert patch that encloses asm-offset.h numbers in brackets

[Linus Torvalds]

On Mon, Oct 25, 2010 at 8:05 AM, Jan Beulich <JBeulich@novell.com> wrote:
>
> Alexander, you seem to be having access to a worst case system -
> could you give this a try?

This all seems very wrong.

The whole "add parenthesis" seems to break several architectures
(Power apparently had problems too due to redefining one of the
macros), and it is ugly.

And the whole thing was added for some stupid gas bug for a very
specific case, and now we're adding _more_ crap to an already ugly
workaround.

How about just removing the idiotic workaround entirely, and then on
x86 passing "-traditional" to cpp for asm input so that it doesn't add
spaces in argument expansion? Make the workaround more targeted to the
actual problem, rather than working around it in some unrelated
thing..

                                       Linus

Re: [PATCH] Partially revert patch that encloses asm-offset.h numbers in brackets

[Jan Beulich]

>>> On 25.10.10 at 17:17, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> How about just removing the idiotic workaround entirely, and then on
> x86 passing "-traditional" to cpp for asm input so that it doesn't add
> spaces in argument expansion? Make the workaround more targeted to the
> actual problem, rather than working around it in some unrelated
> thing..

Hmm, I think it was an actual improvement to remove the use of
-traditional. If fiddling with the globally used sed expression isn't
considered acceptable, how about allowing the architecture to
override it as necessary?

Jan

Re: [PATCH] Partially revert patch that encloses asm-offset.h numbers in brackets

[H. Peter Anvin]

On 10/25/2010 08:17 AM, Linus Torvalds wrote:
> 
> How about just removing the idiotic workaround entirely, and then on
> x86 passing "-traditional" to cpp for asm input so that it doesn't add
> spaces in argument expansion? Make the workaround more targeted to the
> actual problem, rather than working around it in some unrelated
> thing..
> 

We already tried using -traditional, it didn't help the gas braindamage
and it caused severe problems with header files (since -traditional
removes the support for #x and x ## y).  Bringing it back won't help.

As such, the only options I can really think about overriding the sed
expression for x86 or just saying gcc 2.16.90 or later is required...

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH] Partially revert patch that encloses asm-offset.h numbers in brackets

[David Howells]

H. Peter Anvin <hpa@zytor.com> wrote:

> As such, the only options I can really think about overriding the sed
> expression for x86 or just saying gcc 2.16.90 or later is required...

Do you mean binutils-2.16.90?

Davod

Re: [PATCH] Partially revert patch that encloses asm-offset.h numbers in brackets

[Linus Torvalds]

On Mon, Oct 25, 2010 at 8:50 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>
> As such, the only options I can really think about overriding the sed
> expression for x86 or just saying gcc 2.16.90 or later is required...

gas, not gcc. But yeah, maybe we can do that. How long has this space
breakage been going on? If it's a "we got a report from this one guy"
kind of thing, then just saying "we don't support old gas versions
because they are too broken" is probably the right thing to do.

No reason to make for maintenance problems and uglier code if we can
just say "get a newer gas" to a few people. It's not like we haven't
done that with gcc and other tools too.

                       Linus

Re: [PATCH] Partially revert patch that encloses asm-offset.h numbers in brackets

[H. Peter Anvin]

On 10/25/2010 09:16 AM, Linus Torvalds wrote:
> On Mon, Oct 25, 2010 at 8:50 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>>
>> As such, the only options I can really think about overriding the sed
>> expression for x86 or just saying gcc 2.16.90 or later is required...
> 
> gas, not gcc. But yeah, maybe we can do that. How long has this space
> breakage been going on? If it's a "we got a report from this one guy"
> kind of thing, then just saying "we don't support old gas versions
> because they are too broken" is probably the right thing to do.
> 
> No reason to make for maintenance problems and uglier code if we can
> just say "get a newer gas" to a few people. It's not like we haven't
> done that with gcc and other tools too.
> 
>                        Linus

The problem is that 2.16 isn't all that old; al lot of the "enterprise"
distros still ship it or AFAIK even older versions.  2.6.90 which I
*think* is the first fixed version dates from April 2005, so is
currently 5 years old; maybe that is within reason to kill off.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH] Partially revert patch that encloses asm-offset.h numbers in brackets

[H. Peter Anvin]

On 10/25/2010 08:59 AM, David Howells wrote:
> H. Peter Anvin <hpa@zytor.com> wrote:
> 
>> As such, the only options I can really think about overriding the sed
>> expression for x86 or just saying gcc 2.16.90 or later is required...
> 
> Do you mean binutils-2.16.90?

Yes, of course.

	-hpa

Re: [PATCH] Partially revert patch that encloses asm-offset.h numbers in brackets

[Maciej W. Rozycki]

On Mon, 25 Oct 2010, H. Peter Anvin wrote:

> > No reason to make for maintenance problems and uglier code if we can
> > just say "get a newer gas" to a few people. It's not like we haven't
> > done that with gcc and other tools too.
> 
> The problem is that 2.16 isn't all that old; al lot of the "enterprise"
> distros still ship it or AFAIK even older versions.  2.6.90 which I
> *think* is the first fixed version dates from April 2005, so is
> currently 5 years old; maybe that is within reason to kill off.

 For the record -- binutils 2.21 are about to be released and for several 
years now the schedule has roughly been one major release per year, 
sometimes followed by some bug-fix minor releases as needed.  That'll make 
2.16 *five* releases away from the current version and hardly a reason to 
keep maintaining support for it in the face of critical problems.

 If some random distribution insists on maintaining such old tools, then 
it's their responsibility to backport critical fixes, such as these 
required to get the parser (or whatever piece of code is responsible for 
the breakage observed here) right, isn't it?  Then once they did it, they 
can patch up their kernels to accept their tools too.

 Also note that *.*.9x versions are snapshots from the FSF repository (so 
there's no fixed date associated with them), which also delegates 
maintenance responsibility to whoever packages them and makes available to 
people.  In the state as imported from the repository they may have odd 
problems or grave bugs, as exhaustive regression testing is generally only 
made after a release branch has been created and otherwise changes to the 
head of the tree are only tested for a limited subset of targets before 
they are applied.  Therefore local fixes are inevitable for them anyway.

 And last but not least binutils are one of the easier tools to build from 
sources, so installing a newer version, especially when it comes to native 
tools (hardly anyone uses cross-compilation targeting x86, I believe), 
somewhere under $HOME to use for kernel builds is a trivial effort:

$ ./configure --prefix=$HOME/somewhere && make && make install
$ PATH=$HOME/somewhere/bin:$PATH

Certainly much easier than building the kernel, especially when it comes 
to selecting the right configuration options.

  Maciej

Re: [PATCH] Partially revert patch that encloses asm-offset.h numbers in brackets

[H. Peter Anvin]

On 10/26/2010 03:53 AM, Maciej W. Rozycki wrote:
> 
>  Also note that *.*.9x versions are snapshots from the FSF repository (so 
> there's no fixed date associated with them), which also delegates 
> maintenance responsibility to whoever packages them and makes available to 
> people.  In the state as imported from the repository they may have odd 
> problems or grave bugs, as exhaustive regression testing is generally only 
> made after a release branch has been created and otherwise changes to the 
> head of the tree are only tested for a limited subset of targets before 
> they are applied.  Therefore local fixes are inevitable for them anyway.
> 

Well, sort of... the x.x.9x releases used in production -- specifically
the ones with a numbering scheme like x.x.9x.0.x -- in the Linux world
tend to be the ones maintained and released by H.J. Lu:

http://www.kernel.org/pub/linux/devel/binutils/

>  And last but not least binutils are one of the easier tools to build from 
> sources, so installing a newer version, especially when it comes to native 
> tools (hardly anyone uses cross-compilation targeting x86, I believe), 
> somewhere under $HOME to use for kernel builds is a trivial effort:
> 
> $ ./configure --prefix=$HOME/somewhere && make && make install
> $ PATH=$HOME/somewhere/bin:$PATH
> 
> Certainly much easier than building the kernel, especially when it comes 
> to selecting the right configuration options.

Yes, although there is also a version dependency between binutils and
gcc, as I unhappily found out trying to run an upversion gcc on an old
distro at one point.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH] Partially revert patch that encloses asm-offset.h numbers in brackets

[Maciej W. Rozycki]

On Tue, 26 Oct 2010, H. Peter Anvin wrote:

> >  Also note that *.*.9x versions are snapshots from the FSF repository (so 
> > there's no fixed date associated with them), which also delegates 
> > maintenance responsibility to whoever packages them and makes available to 
> > people.  In the state as imported from the repository they may have odd 
> > problems or grave bugs, as exhaustive regression testing is generally only 
> > made after a release branch has been created and otherwise changes to the 
> > head of the tree are only tested for a limited subset of targets before 
> > they are applied.  Therefore local fixes are inevitable for them anyway.
> 
> Well, sort of... the x.x.9x releases used in production -- specifically
> the ones with a numbering scheme like x.x.9x.0.x -- in the Linux world
> tend to be the ones maintained and released by H.J. Lu:
> 
> http://www.kernel.org/pub/linux/devel/binutils/

 Yeah, in practice this means the packagers have an additional choice to 
pester H.J. if something goes wrong. ;)

 I used H.J.'s releases once too, then around 2.9.4 I switched over to 
pristine FSF sources as I figured out I needed to make own fixes for the 
MIPS port and it was easier for me to propagate them upstream this way.  
And overall I found no problems (apart from the usual bugs here and there 
every once in a while) having since used them for the Alpha, MIPS, VAX and 
x86 ports of Linux (OK, perhaps x86 is not a port ;) ), so the choice 
between the two flavours is mostly the matter of taste it would seem.

> >  And last but not least binutils are one of the easier tools to build from 
> > sources, so installing a newer version, especially when it comes to native 
> > tools (hardly anyone uses cross-compilation targeting x86, I believe), 
> > somewhere under $HOME to use for kernel builds is a trivial effort:
> > 
> > $ ./configure --prefix=$HOME/somewhere && make && make install
> > $ PATH=$HOME/somewhere/bin:$PATH
> > 
> > Certainly much easier than building the kernel, especially when it comes 
> > to selecting the right configuration options.
> 
> Yes, although there is also a version dependency between binutils and
> gcc, as I unhappily found out trying to run an upversion gcc on an old
> distro at one point.

 Fair enough if you do it this way, but switching to a higher version of 
binutils shouldn't ever be a problem.  GCC detects some binutils features 
at the configuration time and sets itself up accordingly, but these do not 
get removed, at least not that I heard of.

  Maciej

Re: [PATCH] Partially revert patch that encloses asm-offset.h numbers in brackets

[Alexander van Heukelum]

On Mon, 25 Oct 2010 16:05 +0100, "Jan Beulich" <JBeulich@novell.com> wrote:
> >>> On 25.10.10 at 16:54, David Howells <dhowells@redhat.com> wrote:
> > Jan Beulich <JBeulich@novell.com> wrote:
> > 
> >> Isn't this a gas bug then? Anywhere you use a plain number you
> >> should also be permitted to use an expression.
> > 
> > Whoever defined the gas assembly syntax for binutils specified that (N) as 
> > an
> > operand defines an absolute address and N defines an immediate value.
> > 
> > However, prefixing an expression with a unary plus works for me, so adding
> > this into my patch:
> > 
> > -	s:^->\([^ ]*\) [\$$#]*\([-0-9]*\) \(.*\):#define \1 \2 /* \3 */:; \
> > +	s:^->\([^ ]*\) [\$$#]*\([-0-9]*\) \(.*\):#define \1 +(\2) /* \3 */:; \
> > 
> > Does that work for you?
> 
> Alexander, you seem to be having access to a worst case system -
> could you give this a try?

Hi all!

I'm just back from a week of vacation, so I missed the discussion completely.

I didn't check the version with the plus-sign, but the current state in linus' tree
compiles fine(*) with this ubuntu 6.06 image. So I'ld suggest to clean up the
sed-script to the old version and limp on a few more kernel versions, watch out
for checkpatch-improvements, and then try again to deprecate gas-2.16, notify
Andrew Morton he should get rid of it, and clean up the space-removals again.

(*) First try was with a UP-PREEMPT-mini.config and this one ended with:
In file included from /home/src/linux/linux-2.6/arch/x86/include/asm/suspend_32.h:10,
                 from /home/src/linux/linux-2.6/arch/x86/include/asm/suspend.h:2,
                 from /home/src/linux/linux-2.6/arch/x86/kernel/asm-offsets_32.c:21,
                 from /home/src/linux/linux-2.6/arch/x86/kernel/asm-offsets.c:2:
/home/src/linux/linux-2.6/arch/x86/include/asm/i387.h: In function ‘irq_ts_save’:
/home/src/linux/linux-2.6/arch/x86/include/asm/i387.h:325: error: implicit declaration of function ‘kernel_locked’
make[2]: *** [arch/x86/kernel/asm-offsets.s] Error 1

Not sure if this is already known. Configuration:

The mini.config file:

CONFIG_EXPERIMENTAL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_RCU_FANOUT=32
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="../initramfs.i386"
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_PREEMPT=y
CONFIG_X86_MCE=y
CONFIG_CC_STACKPROTECTOR=y
CONFIG_HZ_100=y
CONFIG_RELOCATABLE=y
CONFIG_BINFMT_ELF=y
CONFIG_NET=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_PROC_FS=y
CONFIG_SYSFS=y
CONFIG_FRAME_WARN=196
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_RODATA=y
CONFIG_OPTIMIZE_INLINING=y

(can be expanded with "make KCONFIG_ALLCONFIG=mini.config allnoconfig")

Removing CONFIG_PREEMPT=y got things going.

Greetings,
   Alexander

> Thanks, Jan
> 

Re: [PATCH] Partially revert patch that encloses asm-offset.h numbers in brackets

[Ming Lei]

2010/10/31 Alexander van Heukelum <heukelum@fastmail.fm>:
> In file included from /home/src/linux/linux-2.6/arch/x86/include/asm/suspend_32.h:10,
>                 from /home/src/linux/linux-2.6/arch/x86/include/asm/suspend.h:2,
>                 from /home/src/linux/linux-2.6/arch/x86/kernel/asm-offsets_32.c:21,
>                 from /home/src/linux/linux-2.6/arch/x86/kernel/asm-offsets.c:2:
> /home/src/linux/linux-2.6/arch/x86/include/asm/i387.h: In function ‘irq_ts_save’:
> /home/src/linux/linux-2.6/arch/x86/include/asm/i387.h:325: error: implicit declaration of function ‘kernel_locked’
> make[2]: *** [arch/x86/kernel/asm-offsets.s] Error 1

This also touches me too on .37-rc1, any patch for the compile failure?

thanks,
-- 
Lei Ming

Re: [PATCH] Partially revert patch that encloses asm-offset.h numbers in brackets

[Alexander van Heukelum]

On Tue, 02 Nov 2010 16:30 +0800, "Ming Lei" <tom.leiming@gmail.com> wrote:
> 2010/10/31 Alexander van Heukelum <heukelum@fastmail.fm>:
> > In file included from /home/src/linux/linux-2.6/arch/x86/include/asm/suspend_32.h:10,
> >                 from /home/src/linux/linux-2.6/arch/x86/include/asm/suspend.h:2,
> >                 from /home/src/linux/linux-2.6/arch/x86/kernel/asm-offsets_32.c:21,
> >                 from /home/src/linux/linux-2.6/arch/x86/kernel/asm-offsets.c:2:
> > /home/src/linux/linux-2.6/arch/x86/include/asm/i387.h: In function ‘irq_ts_save’:
> > /home/src/linux/linux-2.6/arch/x86/include/asm/i387.h:325: error: implicit declaration of function ‘kernel_locked’
> > make[2]: *** [arch/x86/kernel/asm-offsets.s] Error 1
> 
> This also touches me too on .37-rc1, any patch for the compile failure?

I think this one fixes it:

http://lkml.org/lkml/2010/10/28/151

Greetings,
    Alexander

> thanks,
> -- 
> Lei Ming
>