Bug #661

acpi module failing to load in 1.9.0 preview #4?

Added by dave over 7 years ago. Updated about 7 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

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
certainly missing.

r_esp is defined static in sys/platform/pc32/acpica5/acpi_wakeup.c.
Removing the static...

% cvs diff acpi_wakeup.c
Index: /usr/src/sys/platform/pc32/acpica5/acpi_wakeup.c
=============================================================
RCS file:
/home/dragonfly/cvs/src/sys/platform/pc32/acpica5/acpi_wakeup.c,v
retrieving revision 1.14
diff -r1.14 acpi_wakeup.c
69c69
< 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.

History

#1 Updated by dillon over 7 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.
:
:--
:David Murray

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.

-Matt
Matthew Dillon
<>

#2 Updated by dave over 7 years ago

Hi Matt,

On 28/5/07 6:24 pm, Matthew Dillon wrote:

Yup, adding back the static and removing the initialiser also fixed the
problem.

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 over 7 years ago

:Yup, adding back the static and removing the initialiser also fixed the
:problem.
:
: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!).
:
:--
:David Murray

Ok. Two birds with one stone then... I've removed the unneeded
static initialization in HEAD.

-Matt
Matthew Dillon
<>

#4 Updated by qhwt+dfly over 7 years ago

But a question remains: why the asm code can't see a static variable
with initializer only when it's compiled with GCC4.1?

Cheers.

#5 Updated by joerg over 7 years ago

Because it is a module and GCC 3.4 still would have created the symbol.
At least that's my bet. The in-kernel linker has a few flaws, like not
checking visibility correctly.

#6 Updated by corecode over 7 years ago

I just tried with the initializer and gcc41 and I can not reproduce this problem. Can we get some more data points?

cheers
simon

#7 Updated by qhwt+dfly over 7 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
#include <stdio.h>

static int foo = 1;
int get_foo(void);
__asm__("\n\
.text \n\
.p2align 2, 0x90 \n\
_get_foo: \n\
movl _foo,%eax \n\
movl $1,_foo \n\
ret \n\
");

int
main()
{
printf("foo: %d\n", get_foo());
return 0;
}
$ 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:
_foo
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.

Cheers.

#8 Updated by dillon over 7 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
inline code).

Isn't that fun?

-Matt

#9 Updated by dave over 7 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.

Also available in: Atom PDF