acpi module failing to load in 1.9.0 preview #4?
Having built world and kernel from the 1.9.0 preview #4 sources, I found
this in the system boot messages:
DragonFly 1.9.0-PREVIEW #4: Sun May 20 22:43:30 BST 2007
Preloaded elf kernel "/kernel" at 0xc048b000.
Preloaded elf module "/modules/acpi.ko" at 0xc048b210.
link_elf: symbol r_esp undefined
I presume this means the acpi module wasn't loading; its sysctls were
r_esp is defined static in sys/platform/pc32/acpica5/acpi_wakeup.c.
Removing the static...
% cvs diff acpi_wakeup.c
retrieving revision 1.14
diff -r1.14 acpi_wakeup.c
< static uint32_t r_esp = 0;
> uint32_t r_esp = 0;
..made the problem go away. But since this variable has always been
static, since v1.1 of this file, that doesn't feel right.
I did, by accident, build the kernel as well as the world with GCC v4.1,
so maybe that's the problem.
Apologies if this is user error, and I have a workaround with the
removed static for now.
#1 Updated by dillon about 8 years ago
:r_esp is defined static in sys/platform/pc32/acpica5/acpi_wakeup.c.
:Removing the static...
:..made the problem go away. But since this variable has always been
:static, since v1.1 of this file, that doesn't feel right.
:I did, by accident, build the kernel as well as the world with GCC v4.1,
:so maybe that's the problem.
:Apologies if this is user error, and I have a workaround with the
:removed static for now.
hmm. Try making it static again, but remove the '= 0' assignment
(make it the same as the other r_xxx declarations).
The problem is probably due to an incompatibility between gcc-4.x's
object file format and the kernel loader.
#2 Updated by dave about 8 years ago
On 28/5/07 6:24 pm, Matthew Dillon wrote:
Yup, adding back the static and removing the initialiser also fixed the
So my fault for building with GCC 4, contrary to the instructions. :-)
It's the only problem I've found so far, though (apart from a barrel
load of warnings!).
#3 Updated by dillon about 8 years ago
:Yup, adding back the static and removing the initialiser also fixed the
:So my fault for building with GCC 4, contrary to the instructions. :-)
:It's the only problem I've found so far, though (apart from a barrel
:load of warnings!).
Ok. Two birds with one stone then... I've removed the unneeded
static initialization in HEAD.
#7 Updated by qhwt+dfly about 8 years ago
I think I managed to reproduce this with a smaller code, if OP
has -O2 in his CFLAG (this is with gcc 4.0.1 on Mac OS X, so you need
to remove the extra underscores before function and variable names
to try it on DragonFly).
$ cat a.c
static int foo = 1;
.p2align 2, 0x90 \n\
movl _foo,%eax \n\
movl $1,_foo \n\
printf("foo: %d\n", get_foo());
$ gcc -W -Wall a.c
a.c:3: warning: 'foo' defined but not used
$ gcc -O2 -W -Wall a.c
a.c:3: warning: 'foo' defined but not used
/usr/bin/ld: Undefined symbols:
collect2: ld returned 1 exit status
Apparently gcc-4 has no idea(or no longer cares?) that __asm__() code
does modify foo and it happily optimized the variable away to a constant.
#8 Updated by dillon about 8 years ago
It is possible to 'fix' the problem by adjusting the __asm to actually
declare that it is referencing the static variable, but I dunno if it
is worth the hassle.
Basically, with all versions of GCC, the compiler does not know SQUAT
about the code that is actually in an __asm() line, EXCEPT for the
variable declarations in the line. For example:
#define fnsave(addr) __asm __volatile("fnsave %0" : "=m" (*(addr)))
Here GCC doesn't have a clue about "fnsave %0". All it knows about
is the C -> ASM conversion of the variable 'addr'.
So if you don't specify a variable list with proper attributes, GCC
will feel free to optimize the hell out of it. In fact, if you do
not specify __volatile GCC will consider removing the __asm line
entirely and if you don't specify the "memory" attribute GCC will feel
free to reorder memory ops around the assembly (when __asm is used for
Isn't that fun?
#9 Updated by dave about 8 years ago
On 29/5/07 3:42 pm, YONETANI Tomokazu wrote:
Yes, I've got -O2 in CFLAGS and the ACPI module was indeed compiled with
this. (I've got -O only in COPTFLAGS, but it looks like that just gets
used for the kernel, not modules.)
I did try rebuilding just the ACPI module with GCC 3.4, but that didn't
make the problem go away, suggesting maybe the issue is in the kernel
loader, not the module. I didn't try re-building the kernel (that takes
a bit longer :-)) but can try if it's useful.