Skip to contentSkip to conversation

Fix vmi time header bug

PATCH In review Zachary Amsden 5 participants 8 messages Mar 12, 2007 – Mar 13, 2007

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Fix vmi time header bug

Some gcc put this function in .init.text because the header didn't match. For 2.6.21-rc.

Zach

include/asm-i386/vmi_time.h +1 -1
Index: linux-2.6.21/include/asm-i386/vmi_time.h
===================================================================
@@ -54,7 +54,7 @@ extern unsigned long vmi_cpu_khz(void);
 
 #ifdef CONFIG_X86_LOCAL_APIC
 extern void __init vmi_timer_setup_boot_alarm(void);
-extern void __init vmi_timer_setup_secondary_alarm(void);
+extern void __devinit vmi_timer_setup_secondary_alarm(void);
 extern void apic_vmi_timer_interrupt(void);
 #endif
 
#1 lore raw
Quoted 15 lines · On Mon, 12 Mar 2007 14:58:08 -0800 Zachary Amsden <[email protected]> wrote:

Some gcc put this function in .init.text because the header didn't match. For 2.6.21-rc.

Zach

[vmi-devinit-header-fix.patch text/plain (606B)]

Index: linux-2.6.21/include/asm-i386/vmi_time.h
===================================================================

include/asm-i386/vmi_time.h extern unsigned long vmi_cpu_khz(void); · line 59

Quoted 7 lines
include/asm-i386/vmi_time.h +1 -1
@@ -54,7 +54,7 @@ extern unsigned long vmi_cpu_khz(void);
 
 #ifdef CONFIG_X86_LOCAL_APIC
 extern void __init vmi_timer_setup_boot_alarm(void);
-extern void __init vmi_timer_setup_secondary_alarm(void);
+extern void __devinit vmi_timer_setup_secondary_alarm(void);
 extern void apic_vmi_timer_interrupt(void);
 #endif

Really truly? I think we have a _lot_ of declarations which omit the section
qualifier altogether. How come they don't all break too?

(ARM (at least) in fact does require the section tagging on the declaration as well as the definition, but we've thus far only fixed that in a couple of places which were causing breakage).

#2 lore raw
Quoted 3 lines · Andrew Morton

Really truly? I think we have a _lot_ of declarations which omit the section
qualifier altogether. How come they don't all break too?

According to the report I have. Perhaps a bogus section qualifier does more damage than an omitted one. I'll get gcc / linker version, but this could be a combination of user error, a strange toolchain, and perhaps a real bug somewhere.

Quoted 4 lines

(ARM (at least) in fact does require the section tagging on the declaration as well as the definition, but we've thus far only fixed that in a couple of places which were causing breakage).

Yes, I was surprised by this as well, and I'm still skeptical about this being the real cause. Still, this reportedly fixed the problem, and is certainly not a bad thing.

Zach

#3 lore raw
In reply to Andrew Morton
Quoted 3 lines · Andrew Morton

Really truly? I think we have a _lot_ of declarations which omit the section
qualifier altogether. How come they don't all break too?

User build was smoking this:

make O=build -j16

This and non-repeatable results make me suspect some kind of build dependency problem, or perhaps a make bug. Still, please apply, as it doesn't hurt.

Zach

#4 lore raw
Quoted 11 lines · Zachary Amsden
Quoted 2 lines · Andrew Morton

Really truly? I think we have a _lot_ of declarations which omit the
section qualifier altogether. How come they don't all break too?

User build was smoking this:

make O=build -j16

This and non-repeatable results make me suspect some kind of build dependency problem, or perhaps a make bug. Still, please apply, as it doesn't hurt.

I don't think the patch should make any difference, so that's not needed.

-Andi

#5 lore raw
Quoted 8 lines · On Tue, 13 Mar 2007 13:45:06 +0100 Andi Kleen <[email protected]> wrote:
Quoted 6 lines · Zachary Amsden
Quoted 2 lines · Andrew Morton

Really truly? I think we have a _lot_ of declarations which omit the
section qualifier altogether. How come they don't all break too?

User build was smoking this:

Quoted 8 lines
Quoted 5 lines

make O=build -j16

This and non-repeatable results make me suspect some kind of build dependency problem, or perhaps a make bug. Still, please apply, as it doesn't hurt.

I don't think the patch should make any difference, so that's not needed.

Correctly matching the section annotation on declarations and definitions is needed by at least ARM. We should ensure that we do this on all future patches and we should also apply this patch if only for this reason.

(The ARM thing is a pain, because the compiler cannot check that the definition and declaration match. However something like sparse could do so).

#6 lore raw
Quoted 8 lines · Andrew Morton

Correctly matching the section annotation on declarations and definitions is needed by at least ARM. We should ensure that we do this on all future patches and we should also apply this patch if only for this reason.

(The ARM thing is a pain, because the compiler cannot check that the definition and declaration match. However something like sparse could do so).

It's also useful documentation. Knowing whether a function is __init is an important part of its interface.

J

#7 lore raw
In reply to Andrew Morton
Quoted 4 lines · Andrew Morton

(The ARM thing is a pain, because the compiler cannot check that the definition and declaration match. However something like sparse could do so).

Well, I guess sparse could do it, but the fact is, this is just a gcc bug. It would be much better if *gcc* just checked the function attributes it cared about. Anybody want to send a bug-report to the gcc lists?

Here's a trivial test-case.

	#define section(x) __attribute__((__section__(x)))

	extern int section(".text.one") test_function(int);

	int section(".text.two") test_function(int arg)
	{
		return arg+1;
	}

and the bug is that gcc doesn't warn about the section mismatch, and still seems to care.

(Now, if gcc doesn't care, missing the section from the declaration could be considered ok. But having explicit but *different* section declarations can clearly not be ok, and it seems that gcc sometimes *does* require sections to match, so it probably should always require them to match exactly).

We could make sparse care, but right now sparse ignores the section attribute *entirely*.

Linus