DragonFlyBSD

: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 
                    <dillon@backplane.com>

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!).

: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 
                    <dillon@backplane.com>

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.

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.

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

cheers
simon

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.

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

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.