kernel BUG at kernel/posix-cpu-timers.c:1389!

1.
Eric Miao :
> On Sat, Oct 31, 2009 at 12:53 AM, E Robertson <e.robertson.svg at gmail.com> wrote:
>> Hi, I've recently migrated some code to 2.6.31 on a sam9263 board and
>> notice this on
>> several occasions. I thought it might be a serial driver port issue
>> since I haven't seen anyone with
>> this problem before, but  that doesn't seem to be the culprit.
>> Is this is known kernel bug?
> 
> Looks like this run_posix_cpu_timers() is called with IRQ enabled, I'd
> suggest you take a look into your arch/arm/mach-xxx/time.c to see if
> your timer irq_action->flags is written with IRQF_DISABLED there.

in arch/arm/mach-at91/at91sam926x_time.c +125
 .flags = IRQF_SHARED | IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,

IRQF_DISABLED is positionned. But on the other hand, I saw in the kernel
booting messages that:
"IRQ 1/rtc0: IRQF_DISABLED is not guaranteed on shared IRQs"

What does this mean ? what is the difference with former way of managing
shared interrupts ?

And above all, what is the proper way to set an IRQ on a shared
interrupt line ?

>> kernel BUG at kernel/posix-cpu-timers.c:1389!
>> Unable to handle kernel NULL pointer dereference at virtual address 00000000
>> pgd = c1d34000
>> [00000000] *pgd=21fad031, *pte=00000000, *ppte=00000000
>> Internal error: Oops: 817 [#1]
>> CPU: 0    Not tainted  (2.6.31.5 #5)
>> PC is at __bug+0x20/0x2c
>> LR is at release_console_sem+0x1b0/0x1e4
>> pc : [<c00da2a0>]    lr : [<c00ece48>]    psr: 60000013
>> sp : c1d2be7c  ip : c1d2bdb4  fp : c1d2be88
>> r10: 4004e108  r9 : c1d2a000  r8 : c030a904
>> r7 : c031f8fc  r6 : c031f900  r5 : c1c89380  r4 : 00000001
>> r3 : 00000000  r2 : c030c0fc  r1 : 00016348  r0 : 00000034
>> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
>> Control: 0005317f  Table: 21d34000  DAC: 00000015
>> Process TEST (pid: 386, stack limit = 0xc1d2a260)
>> Stack: (0xc1d2be7c to 0xc1d2c000)
>> be60:                                                                c1d2bed0
>> be80: c1d2be8c c0100738 c00da290 c1d2beb4 c1d2be9c c00e9c58 c00e6ca0 c030bbf0
>> bea0: c1d2bea0 c1d2bea0 00000001 c1c89380 c031f900 c031f8fc c030a904 c1d2a000
>> bec0: 4004e108 c1d2bee8 c1d2bed4 c00f5cdc c0100710 0000000a c0325890 c1d2bf00
>> bee0: c1d2beec c0108e84 c00f5c94 00000001 c030a904 c1d2bf38 c1d2bf04 c0108ec0
>> bf00: c0108e00 c1c884c0 beb8fa54 c1d2bf80 00000001 c030a904 c031f900 c031f8fc
>> bf20: 00000000 c1d2a000 4004e108 c1d2bf58 c1d2bf3c c00df16c c0108eb4 c030a8d8
>> bf40: 00000001 00000001 00000000 c1d2bf7c c1d2bf5c c010df28 c00df120 c030ddec
>> bf60: 00000001 00000001 000007f0 ffffffff c1d2bf94 c1d2bf80 c010fdd4 c010def0
>> bf80: 00000001 00000000 c1d2bfac c1d2bf98 c00d6070 c010fd10 ffffffff fefff000
>> bfa0: 00000000 c1d2bfb0 c00d6be4 c00d6010 ffffffff 0003fa10 00000000 0000000b
>> bfc0: 00000000 beb8faa8 00000000 000007f0 ffffffff 00000004 4004e108 00014edc
>> bfe0: 4004e528 beb8fa9c 4003840c 40037534 80000010 ffffffff f507a7b8 c87e873f
>> Backtrace:
>> [<c00da280>] (__bug+0x0/0x2c) from [<c0100738>] (run_posix_cpu_timers+0x38/0x79
>> c)
>> [<c0100700>] (run_posix_cpu_timers+0x0/0x79c) from [<c00f5cdc>] (update_process
>> _times+0x58/0x5c)
>> [<c00f5c84>] (update_process_times+0x0/0x5c) from [<c0108e84>] (tick_periodic+0
>> x94/0xb4)
>>  r5:c0325890 r4:0000000a
>> [<c0108df0>] (tick_periodic+0x0/0xb4) from [<c0108ec0>] (tick_handle_periodic+0
>> x1c/0xf4)
>>  r5:c030a904 r4:00000001
>> [<c0108ea4>] (tick_handle_periodic+0x0/0xf4) from [<c00df16c>] (at91sam926x_pit
>> _interrupt+0x5c/0x80)
>> [<c00df110>] (at91sam926x_pit_interrupt+0x0/0x80) from [<c010df28>] (handle_IRQ
>> _event+0x48/0x114)
>>  r7:00000000 r6:00000001 r5:00000001 r4:c030a8d8
>> [<c010dee0>] (handle_IRQ_event+0x0/0x114) from [<c010fdd4>] (handle_level_irq+0
>> xd4/0xec)
>>  r8:ffffffff r7:000007f0 r6:00000001 r5:00000001 r4:c030ddec
>> [<c010fd00>] (handle_level_irq+0x0/0xec) from [<c00d6070>] (asm_do_IRQ+0x70/0x9
>> 8)
>>  r5:00000000 r4:00000001
>> [<c00d6000>] (asm_do_IRQ+0x0/0x98) from [<c00d6be4>] (__irq_usr+0x44/0x80)
>> Exception stack(0xc1d2bfb0 to 0xc1d2bff8)
>> bfa0:                                     ffffffff 0003fa10 00000000 0000000b
>> bfc0: 00000000 beb8faa8 00000000 000007f0 ffffffff 00000004 4004e108 00014edc
>> bfe0: 4004e528 beb8fa9c 4003840c 40037534 80000010 ffffffff
>>  r5:fefff000 r4:ffffffff
>> Code: e1a01000 e59f000c eb004c80 e3a03000 (e5833000)
>> Kernel panic - not syncing: Fatal exception in interrupt
>> Backtrace:
>> [<c00da54c>] (dump_backtrace+0x0/0x10c) from [<c00da68c>] (dump_stack+0x18/0x1c
>> )
>>  r6:c1d2be34 r5:c031fa70 r4:c1c89380
>> [<c00da674>] (dump_stack+0x0/0x1c) from [<c00ec678>] (panic+0x4c/0x12c)
>> [<c00ec62c>] (panic+0x0/0x12c) from [<c00da7dc>] (die+0x12c/0x158)
>>  r3:00010000 r2:00000080 r1:c031fe98 r0:c02e0e08
>> [<c00da6b0>] (die+0x0/0x158) from [<c00dbd54>] (__do_kernel_fault+0x6c/0x7c)
>> [<c00dbce8>] (__do_kernel_fault+0x0/0x7c) from [<c00dbf88>] (do_page_fault+0x22
>> 4/0x244)
>>  r7:c1d2be34 r6:c1c89380 r5:c0309d10 r4:ffffffff
>> [<c00dbd64>] (do_page_fault+0x0/0x244) from [<c00d623c>] (do_DataAbort+0x3c/0xa
>> 0)
>> [<c00d6200>] (do_DataAbort+0x0/0xa0) from [<c00d69e0>] (__dabt_svc+0x40/0x60)
>> Exception stack(0xc1d2be34 to 0xc1d2be7c)
>> be20:                                              00000034 00016348 c030c0fc
>> be40: 00000000 00000001 c1c89380 c031f900 c031f8fc c030a904 c1d2a000 4004e108
>> be60: c1d2be88 c1d2bdb4 c1d2be7c c00ece48 c00da2a0 60000013 ffffffff
>>  r8:c030a904 r7:c031f8fc r6:c031f900 r5:c1d2be68 r4:ffffffff
>> [<c00da280>] (__bug+0x0/0x2c) from [<c0100738>] (run_posix_cpu_timers+0x38/0x79
>> c)
>> [<c0100700>] (run_posix_cpu_timers+0x0/0x79c) from [<c00f5cdc>] (update_process
>> _times+0x58/0x5c)
>> [<c00f5c84>] (update_process_times+0x0/0x5c) from [<c0108e84>] (tick_periodic+0
>> x94/0xb4)
>>  r5:c0325890 r4:0000000a
>> [<c0108df0>] (tick_periodic+0x0/0xb4) from [<c0108ec0>] (tick_handle_periodic+0
>> x1c/0xf4)
>>  r5:c030a904 r4:00000001
>> [<c0108ea4>] (tick_handle_periodic+0x0/0xf4) from [<c00df16c>] (at91sam926x_pit
>> _interrupt+0x5c/0x80)
>> [<c00df110>] (at91sam926x_pit_interrupt+0x0/0x80) from [<c010df28>] (handle_IRQ
>> _event+0x48/0x114)
>>  r7:00000000 r6:00000001 r5:00000001 r4:c030a8d8
>> [<c010dee0>] (handle_IRQ_event+0x0/0x114) from [<c010fdd4>] (handle_level_irq+0
>> xd4/0xec)
>>  r8:ffffffff r7:000007f0 r6:00000001 r5:00000001 r4:c030ddec
>> [<c010fd00>] (handle_level_irq+0x0/0xec) from [<c00d6070>] (asm_do_IRQ+0x70/0x9
>> 8)
>>  r5:00000000 r4:00000001
>> [<c00d6000>] (asm_do_IRQ+0x0/0x98) from [<c00d6be4>] (__irq_usr+0x44/0x80)
>> Exception stack(0xc1d2bfb0 to 0xc1d2bff8)
>> bfa0:                                     ffffffff 0003fa10 00000000 0000000b
>> bfc0: 00000000 beb8faa8 00000000 000007f0 ffffffff 00000004 4004e108 00014edc
>> bfe0: 4004e528 beb8fa9c 4003840c 40037534 80000010 ffffffff
>>  r5:fefff000 r4:ffffffff
>>
>> _______________________________________________
2.
On Mon, Nov 2, 2009 at 10:54 AM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Mon, Nov 02, 2009 at 05:47:57PM +0100, Nicolas Ferre wrote:
>> in arch/arm/mach-at91/at91sam926x_time.c +125
>>  .flags = IRQF_SHARED | IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
>>
>> IRQF_DISABLED is positionned. But on the other hand, I saw in the kernel
>> booting messages that:
>> "IRQ 1/rtc0: IRQF_DISABLED is not guaranteed on shared IRQs"
>>
>> What does this mean ? what is the difference with former way of managing
>> shared interrupts ?
>
> If the first IRQ action which is run was registered without IRQF_DISABLED
> the entire set will be run without interrupts disabled.
>
>> And above all, what is the proper way to set an IRQ on a shared
>> interrupt line ?
>
> The only real solution is to ensure that all requesters use IRQF_DISABLED.
>

I don't see where this could be the cause of this problem. The bug
happens after the system is running and I attempt to use the select
method for polling (serial port & uevents).  Without this the bug [
BUG_ON(!irqs_disabled()); ]  did not occur.  I added the flag to the
requesters but that did not help, maybe I overlooked something.

I notice this change from 2.6.18 but didn't follow why the change.

 --- linux-2.6.31/arch/arm/mach-at91/at91sam926x_time.c	2009-11-05
09:34:49.000000000 -0600
+++ linux-2.6.28/arch/arm/mach-at91/at91sam926x_time.c	2009-02-06
15:47:45.000000000 -0600
@@ -31,7 +31,7 @@
  * Clocksource:  just a monotonic counter of MCK/16 cycles.
  * We don't care whether or not PIT irqs are enabled.
  */
-static cycle_t read_pit_clk(struct clocksource *cs)
+static cycle_t read_pit_clk(void)
 {
 	unsigned long flags;
 	u32 elapsed;
@@ -91,6 +91,7 @@
 	.features	= CLOCK_EVT_FEAT_PERIODIC,
 	.shift		= 32,
 	.rating		= 100,
+	.cpumask	= CPU_MASK_CPU0,
 	.set_mode	= pit_clkevt_mode,
 };

@@ -172,7 +173,6 @@

 	/* Set up and register clockevents */
 	pit_clkevt.mult = div_sc(pit_rate, NSEC_PER_SEC, pit_clkevt.shift);
-	pit_clkevt.cpumask = cpumask_of(0);
 	clockevents_register_device(&pit_clkevt);
 }
3.
On Thu, Nov 05, 2009 at 11:07:41AM -0600, E Robertson wrote:
> On Mon, Nov 2, 2009 at 10:54 AM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > On Mon, Nov 02, 2009 at 05:47:57PM +0100, Nicolas Ferre wrote:
> >> in arch/arm/mach-at91/at91sam926x_time.c +125
> >>  .flags = IRQF_SHARED | IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
> >>
> >> IRQF_DISABLED is positionned. But on the other hand, I saw in the kernel
> >> booting messages that:
> >> "IRQ 1/rtc0: IRQF_DISABLED is not guaranteed on shared IRQs"
> >>
> >> What does this mean ? what is the difference with former way of managing
> >> shared interrupts ?
> >
> > If the first IRQ action which is run was registered without IRQF_DISABLED
> > the entire set will be run without interrupts disabled.
> >
> >> And above all, what is the proper way to set an IRQ on a shared
> >> interrupt line ?
> >
> > The only real solution is to ensure that all requesters use IRQF_DISABLED.
> >
> 
> I don't see where this could be the cause of this problem. The bug
> happens after the system is running and I attempt to use the select
> method for polling (serial port & uevents).  Without this the bug [
> BUG_ON(!irqs_disabled()); ]  did not occur.  I added the flag to the
> requesters but that did not help, maybe I overlooked something.

Well, run_posix_cpu_timers() must be called with interrupts disabled.
This bug indicates that this has been violated.

Since we know that the timer stuff works on virtually every other
platform which makes use of the generic time infrastructure, I doubt
you've found a bug in it - so that tends to eliminate tick_handle_periodic()
and below in the call chain.  (Oh how I absolutely detest how genirq is
completely undocumented with respect to details like this, and people
are left to guess.)

So, the only thing that leaves is that tick_handle_periodic() was called
with IRQs enabled.

You could try putting a BUG_ON(!irqs_disabled()) in parent functions to
trace where interrupts are being re-enabled, but I think you'll find that
at91sam926x_pit_interrupt() was called with IRQs enabled.

Now, for any shared interrupt, where some handlers are registered with
IRQF_DISABLED and non-IRQF_DISABLED can lead to IRQF_DISABLED handlers
being called with IRQs enabled (hence the "IRQF_SHARED is not guaranteed
on shared IRQs" warning).  So... the solution is as I said above.
4.
On Mon, Nov 02, 2009 at 04:54:41PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 02, 2009 at 05:47:57PM +0100, Nicolas Ferre wrote:
> > in arch/arm/mach-at91/at91sam926x_time.c +125
> >  .flags = IRQF_SHARED | IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
> > 
> > IRQF_DISABLED is positionned. But on the other hand, I saw in the kernel
> > booting messages that:
> > "IRQ 1/rtc0: IRQF_DISABLED is not guaranteed on shared IRQs"
> > 
> > What does this mean ? what is the difference with former way of managing
> > shared interrupts ?
> 
> If the first IRQ action which is run was registered without IRQF_DISABLED
> the entire set will be run without interrupts disabled.
... unless one of the handlers enables irqs, so all bets are off for all
but the first handler.
 
> > And above all, what is the proper way to set an IRQ on a shared
> > interrupt line ?
> 
> The only real solution is to ensure that all requesters use IRQF_DISABLED.
Back to the original problem: can you provide the contents of
/proc/interrupts and the output of dmesg?

I once saw that an oops containing the last time and location when irqs
where enabled and disabled.  That would be great here.  I don't know
off-hand where to find a patch and it doesn't seem to be supported in
mainline.  I will come back on this.
make -C src all make[1]: Entering directory '/home/zzuer/Lyp_folder/pmdk/src' make -C libpmem make[2]: Entering directory '/home/zzuer/Lyp_folder/pmdk/src/libpmem' cc -MD -c -o ../nondebug/libpmem/file.o -Wno-error -std=gnu99 -I../include -I../common/ -fPIC ../../src/../src/common/file.c ../../src/../utils/check-os.sh ../../src/../utils/os-banned ../nondebug/libpmem/file.o ../../src/../src/common/file.c cc -MD -c -o ../nondebug/libpmem/file_posix.o -Wno-error -std=gnu99 -I../include -I../common/ -fPIC ../../src/../src/common/file_posix.c ../../src/../utils/check-os.sh ../../src/../utils/os-banned ../nondebug/libpmem/file_posix.o ../../src/../src/common/file_posix.c cc -MD -c -o ../nondebug/libpmem/fs_posix.o -Wno-error -std=gnu99 -I../include -I../common/ -fPIC ../../src/../src/common/fs_posix.c ../../src/../utils/check-os.sh ../../src/../utils/os-banned ../nondebug/libpmem/fs_posix.o ../../src/../src/common/fs_posix.c cc -MD -c -o ../nondebug/libpmem/mmap.o -Wno-error -std=gnu99 -I../include -I../common/ -fPIC ../../src/../src/common/mmap.c ../../src/../utils/check-os.sh ../../src/../utils/os-banned ../nondebug/libpmem/mmap.o ../../src/../src/common/mmap.c cc -MD -c -o ../nondebug/libpmem/mmap_posix.o -Wno-error -std=gnu99 -I../include -I../common/ -fPIC ../../src/../src/common/mmap_posix.c ../../src/../utils/check-os.sh ../../src/../utils/os-banned ../nondebug/libpmem/mmap_posix.o ../../src/../src/common/mmap_posix.c cc -MD -c -o ../nondebug/libpmem/os_posix.o -Wno-error -std=gnu99 -I../include -I../common/ -fPIC ../../src/../src/common/os_posix.c ../../src/../utils/check-os.sh ../../src/../utils/os-banned ../nondebug/libpmem/os_posix.o ../../src/../src/common/os_posix.c cc -MD -c -o ../nondebug/libpmem/os_thread_posix.o -Wno-error -std=gnu99 -I../include -I../common/ -fPIC ../../src/../src/common/os_thread_posix.c ../../src/../utils/check-os.sh ../../src/../utils/os-banned ../nondebug/libpmem/os_thread_posix.o ../../src/../src/common/os_thread_posix.c cc -MD -c -o ../nondebug/libpmem/os_deep_linux.o -Wno-error -std=gnu99 -I../include -I../common/ -fPIC ../../src/../src/common/os_deep_linux.c ../../src/../utils/check-os.sh ../../src/../utils/os-banned ../nondebug/libpmem/os_deep_linux.o ../../src/../src/common/os_deep_linux.c cc -MD -c -o ../nondebug/libpmem/os_auto_flush_linux.o -Wno-error -std=gnu99 -I../include -I../common/ -fPIC ../../src/../src/common/os_auto_flush_linux.c ../../src/../utils/check-os.sh ../../src/../utils/os-banned ../nondebug/libpmem/os_auto_flush_linux.o ../../src/../src/common/os_auto_flush_linux.c cc -MD -c -o ../nondebug/libpmem/out.o -Wno-error -std=gnu99 -I../include -I../common/ -fPIC ../../src/../src/common/out.c ../../src/../src/common/out.c: In function ‘out_init’: ../../src/../src/common/out.c:241:20: error: expected ‘,’ or ‘;’ before ‘SRCVERSION’ 241 | "src version: " SRCVERSION; | ^~~~~~~~~~ make[2]: *** [../Makefile.inc:304: ../nondebug/libpmem/out.o] Error 1 make[2]: Leaving directory '/home/zzuer/Lyp_folder/pmdk/src/libpmem' make[1]: *** [Makefile:167: libpmem] Error 2 make[1]: Leaving directory '/home/zzuer/Lyp_folder/pmdk/src' make: *** [Makefile:83: all] Error 2
最新发布
05-30
<think>好的,我现在需要解决用户在使用make编译时出现的错误:在out.c文件中遇到了‘expected ‘,’ or‘;’ before‘SRCVERSION’错误。用户之前尝试的编译命令是makeCFLAGS+="-Wno-error" -std=gnu99,但显然有问题。首先,我需要分析这个错误的原因。根据用户提供的引用内容,特别是引用[1]中提到在编译riscv-gnu-toolchain时需要多次makeclean,否则可能报错,这可能意味着代码中存在依赖或缓存问题。但用户当前的错误看起来是语法错误,可能和宏定义有关。引用[3]中的海思官方Makefile示例显示,他们使用了-D选项来定义宏,比如-DVER_X=1,这可能与用户的SRCVERSION宏定义有关联。 用户提到的错误是expected‘,’or ‘;’before ‘SRCVERSION’,这通常发生在宏定义被错误地使用或者宏名与系统保留的宏冲突时。例如,如果SRCVERSION在某个头文件中已经被定义为一个带参数的宏,而用户试图将其作为字符串使用,就会导致语法错误。比如,假设系统头文件中定义了一个宏SRCVERSION为某个函数或变量,而用户代码中使用了类似"srcversion:" SRCVERSION;这样的语句,这时预处理器会将SRCVERSION替换,导致语法错误。查看用户之前的对话历史,用户曾修改过SRCVERSION为GIT_SRCVERSION以避免冲突,这说明问题可能出在宏名冲突上。因此,解决方案需要确保用户代码中的宏名不与系统或第三方库中的宏名冲突。需要检查所有使用SRCVERSION的地方,并重命名。另外,用户的编译命令是否正确?用户使用了CFLAGS+="-Wno-error" -std=gnu99,这可能存在问题,因为CFLAGS+=的用法是否正确?在Makefile中,CFLAGS+=是追加变量,但在命令行中直接使用CFLAGS+=可能被误解。正确的做法应该是将两个参数合并,如CFLAGS="-Wno-error-std=gnu99",这样确保同时传递这两个选项。用户之前的回答中也提到过这一点,所以需要确认用户是否正确地合并了参数。 此外,用户是否在修改宏名后进行了全面的替换?比如,在头文件common.inc中将SRCVERSION改为GIT_SRCVERSION,并在所有引用该宏的源文件(如out.c)中也进行了相应的修改。如果只修改了头文件而忽略了源文件中的引用,或者反之,都会导致错误。此外,是否在修改后执行了make clean以清除旧的编译缓存?引用[1]中提到多次编译可能需要先清理,否则残留的中间文件可能导致错误依旧存在。 再者,检查编译器的标准是否符合。用户使用了-std=gnu99,这是为了确保C99标准,但需要确认编译器是否真的支持该标准,或者是否存在其他语法问题。例如,C99允许在for循环内部声明变量,而旧标准不允许,如果代码中有这样的结构,没有正确指定标准也会导致错误。不过用户当前的错误是宏相关,可能和标准关系不大,但依然需要确认。 还需要考虑是否在编译命令中正确定义了宏。比如,在引用[3]中,使用-D选项定义了很多宏,用户是否需要类似的定义?如果SRCVERSION应该由Makefile定义,那么是否在CFLAGS中添加了-DSRCVERSION="1.4"这样的选项?如果用户代码中声明了SRCVERSION而没有定义,或者定义方式不正确,也会导致错误。总结可能的解决步骤:1.检查所有使用SRCVERSION的地方,确保宏名被正确替换为不冲突的名称,如GIT_SRCVERSION,并确保头文件和源文件中的修改一致。 2.正确设置编译命令,合并CFLAGS参数,避免语法错误,如使用make CFLAGS="-Wno-error-std=gnu99"。3.执行make clean清除旧的编译结果,避免残留文件干扰。 4.确保在需要的地方通过-D选项定义宏,或者在代码中正确定义宏。5.检查是否有其他头文件包含了与SRCVERSION冲突的宏定义,可能需要调整包含顺序或使用#undef。 此外,参考用户之前的回答,修改宏定义和编译参数是关键步骤。需要指导用户正确组合编译选项,彻底替换宏名,并清理编译环境。</think>### 分步解决方案 #### 1. **修正编译参数语法** 原命令 `make CFLAGS+="-Wno-error" -std=gnu99` 存在语法错误,需合并参数到 `CFLAGS` 中: ```bash # 正确格式 make CFLAGS="-Wno-error -std=gnu99" ``` 此修改确保编译器同时接受 `-std=gnu99` 和 `-Wno-error` 参数[^1][^3]。 #### 2. **解决宏定义冲突** 错误 `expected ‘,’ or ‘;’ before ‘SRCVERSION’` 通常由以下原因导致: - **原因1**:`SRCVERSION` 被错误地定义为函数式宏而非字符串常量 - **原因2**:`SRCVERSION` 与系统保留宏名冲突 **修改方法**: ```diff // src/common.inc 中修改宏定义 - #define SRCVERSION "1.4" + #define GIT_SRCVERSION "1.4" // out.c 中同步修改引用 - "src version: " SRCVERSION; + "src version: " GIT_SRCVERSION; ``` 此操作隔离用户定义宏与系统保留符号[^1]。 #### 3. **清理编译环境** 残留的旧编译文件可能导致冲突,需先清理: ```bash make clean ``` #### 4. **验证宏展开** 通过预处理器检查宏展开结果: ```bash gcc -E out.c | grep GIT_SRCVERSION ``` 预期输出应包含完整的字符串拼接,如: ```c "src version: " "1.4"; ``` #### 5. **处理内核模块特殊要求** 若涉及内核代码(如 `os_deep_linux.c`),需在模块 `Makefile` 中增加: ```makefile ccflags-y := -std=gnu99 -Wno-declaration-after-statement ``` --- ### 技术原理 1. **参数传递机制**:`CFLAGS` 需通过键值对完整传递,否则 `-std=gnu99` 会被误认为 `make` 的目标参数[^1] 2. **宏隔离策略**:重命名宏可避免与内核头文件中的 `SRCVERSION`(如版本控制相关宏)冲突[^3] 3. **预编译检查**:`gcc -E` 可验证宏展开是否符合预期,定位语法错误根源 --- ### 验证流程 ```bash # 完整执行流程 make clean make CFLAGS="-Wno-error -std=gnu99" # 检查错误是否消失 grep -rn "SRCVERSION" ./src ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值