I started getting following linking error on amd64 after the 2.6.25
patch floodgates were opened:
[snip]
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
arch/x86/vdso/built-in.o: In function `init_vdso_vars':
vma.c:(.init.text+0x170): undefined reference to `VDSO64_vgetcpu_mode'
vma.c:(.init.text+0x1a3): undefined reference to `VDSO64_vsyscall_gtod_data'
vma.c:(.init.text+0x1aa): undefined reference to `VDSO64_vgetcpu_mode'
vma.c:(.init.text+0x1d8): undefined reference to `VDSO64_vsyscall_gtod_data'
make: *** [.tmp_vmlinux1] Error 1
Bisecting turned up following commit:
2b9c97e16101e8dc2b0810d6f932d475a051d785 is first bad commit
commit 2b9c97e16101e8dc2b0810d6f932d475a051d785
Author: Roland McGrath <[email protected]>
Date: Wed Jan 30 13:30:41 2008 +0100
x86 vDSO: remove vdso-syms.o
Get rid of vdso-syms.o from the kernel link. We don't need it any more.
Signed-off-by: Roland McGrath <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Linus Torvalds <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
To test get the error, just disable 32 bit emulation (IA32_EMULATION)
Cheers,
Priit ;)
I was not able to reproduce this failure. Those symbols should be defined
by arch/x86/vdso/vdso-syms.lds, a file generated by the build. If that
file is empty in your build, remove it and see if it gets regenerated
properly, or try a clean build. If the problem persists, please send me
your complete .config file.
Thanks,
Roland
* Roland McGrath <[email protected]> wrote:
> I was not able to reproduce this failure. Those symbols should be
> defined by arch/x86/vdso/vdso-syms.lds, a file generated by the build.
> If that file is empty in your build, remove it and see if it gets
> regenerated properly, or try a clean build. If the problem persists,
> please send me your complete .config file.
if that file is empty, it might be the effect of a Ctrl-C. I sometimes
get that on .o files, if i Ctrl-C a highly parallel make -j at the wrong
moment. (is this expected behavior? It's been like this for a long
time.)
Ingo
> if that file is empty, it might be the effect of a Ctrl-C. I sometimes
> get that on .o files, if i Ctrl-C a highly parallel make -j at the wrong
> moment. (is this expected behavior? It's been like this for a long
> time.)
It is the known situation with the compiler since the dawn of time, yes.
It just writes the file directly, so if it dies in the middle, there's a
file with a fresh date. For things like this done in makefile commands
with >, it has forever been canonical for the anal to use:
... > [email protected]
mv -f [email protected] $@
which avoids the problem. The kernel makefiles are entirely haphazard
about places that do this or don't. It uglifies the commands, but avoids
the problem of freshly-dated but wrong/empty files from botched make runs.
I did not do this in cmd_vdsosym (though I did in cmd_vdso32sym, go figure).
Thanks,
Roland
Sam might want to experiment with something like:
stdout_target = $(1) > $(@D)/.tmp_$(@F) && mv -f $(@D)/.tmp_$(@F) $@
cmd_foo = $(call stdout_target,blah | sed s/foo/bar/)
to clean up all the places that would benefit from robust treatment for
output files vs interrupted/erring make runs.
Thanks,
Roland
Ühel kenal päeval, E, 2008-02-11 kell 14:53, kirjutas Roland McGrath:
> I was not able to reproduce this failure. Those symbols should be defined
> by arch/x86/vdso/vdso-syms.lds, a file generated by the build. If that
> file is empty in your build, remove it and see if it gets regenerated
> properly, or try a clean build. If the problem persists, please send me
> your complete .config file.
This fails with clean build. And vdso-syms.lds is not empty.
Contents of arch/x86/vdso/vdso-syms.lds:
VDSO64_PRELINK = 0xffffffffff700000;
VDSO64_jiffies = 0xffffffffff7004b8;
.config attached or can be viewed at
http://plaes.org/files/2008-Q1/dot_config_VDSO64_error
Hope this helps,
Priit
I did not see it with your .config either.
> This fails with clean build. And vdso-syms.lds is not empty.
>
> Contents of ?arch/x86/vdso/vdso-syms.lds:
> VDSO64_PRELINK = 0xffffffffff700000;
> VDSO64_jiffies = 0xffffffffff7004b8;
Odd. The missing symbols come from the same place that VDSO64_jiffies did.
The end of the arch/x86/vdso/vdso.lds file in your build should have these:
VDSO64_jiffies = vdso_jiffies;
VDSO64_vgetcpu_mode = vdso_vgetcpu_mode;
VDSO64_vsyscall_gtod_data = vdso_vsyscall_gtod_data;
readelf -s arch/x86/vdso/vvar.o in your build should show (among others):
8: 0000000000000000 8 OBJECT GLOBAL DEFAULT 4 vdso_jiffies
9: 0000000000000008 8 OBJECT GLOBAL DEFAULT 4 vdso_vgetcpu_mode
10: 0000000000000010 8 OBJECT GLOBAL DEFAULT 4 vdso_vsyscall_gtod_data
If either of those is not all there, you'll have to look into what's
happening in the generation of the respective files.
Thanks,
Roland
On Feb 11 2008 15:29, Roland McGrath wrote:
>Sam might want to experiment with something like:
>
> stdout_target = $(1) > $(@D)/.tmp_$(@F) && mv -f $(@D)/.tmp_$(@F) $@
>
> cmd_foo = $(call stdout_target,blah | sed s/foo/bar/)
>
>to clean up all the places that would benefit from robust treatment for
>output files vs interrupted/erring make runs.
In most cases however, issuing ctrl+c signals make and make will
remove the output file.
Problematic indeed, "temp" could be left when ctrl+c is hit:
foo: bar
generate-something <bar >temp;
add-up <temp >foo;
What could work, temp being removed on ^C:
temp: bar
generate-something <bar >temp;
foo: temp
add-up <temp >foo;