Hi,
Trying to compile 2.6.38, I found the follwoing bug. Compiler barks...
diff linux-2.6.38/arch/x86/kernel/entry_32.S
linux-2.6.38/arch/x86/kernel/entry_32.S~
1416c1416
< END(async_page_fault)
---
> END(apf_page_fault)
--eric
On Wed, Mar 16, 2011 at 02:15:26PM +0100, Eric Valette wrote:
> Hi,
>
> Trying to compile 2.6.38, I found the follwoing bug. Compiler barks...
New compiler? (new binutils more likely)
>
> diff linux-2.6.38/arch/x86/kernel/entry_32.S
> linux-2.6.38/arch/x86/kernel/entry_32.S~
> 1416c1416
> < END(async_page_fault)
> ---
> > END(apf_page_fault)
>
Ingo and Thomas,
IIRC, you have patches to fix these, right?
Thanks,
-- Steve
On 16/03/2011 20:52, Steven Rostedt wrote:
> On Wed, Mar 16, 2011 at 02:15:26PM +0100, Eric Valette wrote:
>> Hi,
>>
>> Trying to compile 2.6.38, I found the follwoing bug. Compiler barks...
>
> New compiler? (new binutils more likely)
Maybe. I use debian unstable + experimental and upgrade packages almost
everyday...
>>
>> diff linux-2.6.38/arch/x86/kernel/entry_32.S
>> linux-2.6.38/arch/x86/kernel/entry_32.S~
>> 1416c1416
>> < END(async_page_fault)
>> ---
>>> END(apf_page_fault)
But obviously the begin end is not symmetric as in other function.
>>
>
> Ingo and Thomas,
>
> IIRC, you have patches to fix these, right?
>
> Thanks,
>
> -- Steve
>
On Wed, 2011-03-16 at 21:09 +0100, Eric Vlette wrote:
> On 16/03/2011 20:52, Steven Rostedt wrote:
> > On Wed, Mar 16, 2011 at 02:15:26PM +0100, Eric Valette wrote:
> >> Hi,
> >>
> >> Trying to compile 2.6.38, I found the follwoing bug. Compiler barks...
> >
> > New compiler? (new binutils more likely)
>
> Maybe. I use debian unstable + experimental and upgrade packages almost
> everyday...
You probably have new binutils.
What does "as --version" give you. Binutils 2.21... ?
I think it was 2.21 that started giving problems.
>
> >>
> >> diff linux-2.6.38/arch/x86/kernel/entry_32.S
> >> linux-2.6.38/arch/x86/kernel/entry_32.S~
> >> 1416c1416
> >> < END(async_page_fault)
> >> ---
> >>> END(apf_page_fault)
>
> But obviously the begin end is not symmetric as in other function.
Right, there was a discussion before about this causing issues with new
binutils, and I think Ingo or Thomas said that they had patches to fix
these for x86. Which this looks like one.
The old binutils never complained.
-- Steve
On 16/03/2011 21:22, Steven Rostedt wrote:
> On Wed, 2011-03-16 at 21:09 +0100, Eric Vlette wrote:
>> On 16/03/2011 20:52, Steven Rostedt wrote:
>>> On Wed, Mar 16, 2011 at 02:15:26PM +0100, Eric Valette wrote:
>>>> Hi,
>>>>
>>>> Trying to compile 2.6.38, I found the follwoing bug. Compiler barks...
>>>
>>> New compiler? (new binutils more likely)
>>
>> Maybe. I use debian unstable + experimental and upgrade packages almost
>> everyday...
>
> You probably have new binutils.
>
> What does "as --version" give you. Binutils 2.21... ?
Well I found the problem at work and I'm home now but since I use the
same distrib and just updated, its probably the same.
as --version
GNU assembler (GNU Binutils for Debian) 2.21.0.20110302
So probably most debian user will soon or late have the problem.
> I think it was 2.21 that started giving problems.
Sound plausible.
>> But obviously the begin end is not symmetric as in other function.
>
> Right, there was a discussion before about this causing issues with new
> binutils, and I think Ingo or Thomas said that they had patches to fix
> these for x86. Which this looks like one.
>
> The old binutils never complained.
Anyway this show once again that the world like symetry and you better
remember it ;-) (lock/unlock, malloc free, ...)
Probably a stable candidate for 2.6.38.1
--eric
On Wed, 2011-03-16 at 21:32 +0100, Eric Valette wrote:
> > The old binutils never complained.
>
> Anyway this show once again that the world like symetry and you better
> remember it ;-) (lock/unlock, malloc free, ...)
Right, but it should be a warning not an error. If it worked before, why
not work now and just warn about it. This "BUG" existed forever in the
kernel, and its in more than one place. Having the compiler crash on the
first instance means you need to fix it and run the compiler again to
find the next instance and so on.
binutils made a fatal error in making this a bug and not an warning.
>
> Probably a stable candidate for 2.6.38.1
Perhaps, but what about all older kernels. Now this version of binutils
does not work for bisecting.
-- Steve
On 16/03/2011 21:44, Steven Rostedt wrote:
> On Wed, 2011-03-16 at 21:32 +0100, Eric Valette wrote:
>
>
>>> The old binutils never complained.
>>
>> Anyway this show once again that the world like symetry and you better
>> remember it ;-) (lock/unlock, malloc free, ...)
>
> Right, but it should be a warning not an error. If it worked before, why
> not work now and just warn about it. This "BUG" existed forever in the
> kernel, and its in more than one place. Having the compiler crash on the
> first instance means you need to fix it and run the compiler again to
> find the next instance and so on.
Yes like any other name change in a .h file with incompatible function
signature...
The exact error message is a complaint about the .size directive not
being a "constant"...
> binutils made a fatal error in making this a bug and not an warning.
>
>>
>> Probably a stable candidate for 2.6.38.1
>
> Perhaps, but what about all older kernels. Now this version of binutils
> does not work for bisecting.
I guess its binutils git of the 2011/03/02
As far as I'm concerned I only found one occurence on one machine
although I compiled tree 2.6.38 kernels for different machines.
because its under the CONFIG_KVM_GUEST flag
--eric
* Eric Valette <[email protected]> wrote:
> I guess its binutils git of the 2011/03/02
>
> As far as I'm concerned I only found one occurence on one machine
> although I compiled tree 2.6.38 kernels for different machines.
> because its under the CONFIG_KVM_GUEST flag
Unofortunately there's also a CONFIG_XEN=y build breakage caused by this new
binutils behavior, going back from v2.6.38 to v2.6.27-rc1 and breaking
bisection builds for over 130,000 commits covering an almost 3 years window of
kernel history.
GAS allowed such debug symbol mismatches for over a decade and never reported
anything. It's nice that binutils now checks for this condition (we need more
automation in this area) and the most helpful would be for the assembler to
report the mismatch via a new *warning* - and by also ignore the symbol in
question.
Instead this harmless condition was escallated into an unnecessary,
retroactive, show-stopping build failure, which is an exceedingly lame and
harmful. Tools should be permissive, and they should help not hinder
development.
The kernel side fix is upstream already and i've attached it below. That
obviously does not help bisecting testers who will trigger the build failure
after the first bisection step ...
Thanks,
Ingo
----------------->
>From 371c394af27ab7d1e58a66bc19d9f1f3ac1f67b4 Mon Sep 17 00:00:00 2001
From: Alexander van Heukelum <[email protected]>
Date: Fri, 11 Mar 2011 21:59:38 +0100
Subject: [PATCH] x86, binutils, xen: Fix another wrong size directive
The latest binutils (2.21.0.20110302/Ubuntu) breaks the build
yet another time, under CONFIG_XEN=y due to a .size directive that
refers to a slightly differently named (hence, to the now very
strict and unforgiving assembler, non-existent) symbol.
[ mingo:
This unnecessary build breakage caused by new binutils
version 2.21 gets escallated back several kernel releases spanning
several years of Linux history, affecting over 130,000 upstream
kernel commits (!), on CONFIG_XEN=y 64-bit kernels (i.e. essentially
affecting all major Linux distro kernel configs).
Git annotate tells us that this slight debug symbol code mismatch
bug has been introduced in 2008 in commit 3d75e1b8:
3d75e1b8 (Jeremy Fitzhardinge 2008-07-08 15:06:49 -0700 1231) ENTRY(xen_do_hypervisor_callback) # do_hypervisor_callback(struct *pt_regs)
The 'bug' is just a slight assymetry in ENTRY()/END()
debug-symbols sequences, with lots of assembly code between the
ENTRY() and the END():
ENTRY(xen_do_hypervisor_callback) # do_hypervisor_callback(struct *pt_regs)
...
END(do_hypervisor_callback)
Human reviewers almost never catch such small mismatches, and binutils
never even warned about it either.
This new binutils version thus breaks the Xen build on all upstream kernels
since v2.6.27, out of the blue.
This makes a straightforward Git bisection of all 64-bit Xen-enabled kernels
impossible on such binutils, for a bisection window of over hundred
thousand historic commits. (!)
This is a major fail on the side of binutils and binutils needs to turn
this show-stopper build failure into a warning ASAP. ]
Signed-off-by: Alexander van Heukelum <[email protected]>
Cc: Jeremy Fitzhardinge <[email protected]>
Cc: Jan Beulich <[email protected]>
Cc: H.J. Lu <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Kees Cook <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/kernel/entry_64.S | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index aed1ffb..bbd5c80 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1248,7 +1248,7 @@ ENTRY(xen_do_hypervisor_callback) # do_hypervisor_callback(struct *pt_regs)
decl PER_CPU_VAR(irq_count)
jmp error_exit
CFI_ENDPROC
-END(do_hypervisor_callback)
+END(xen_do_hypervisor_callback)
/*
* Hypervisor uses this for application faults while it executes.