From: Vincentius Robby (vincentius_at_umich_dot_edu)
Date: Fri Sep 05 2008 - 08:59:11 PDT
Hello Paul,
Yes the errors reported went away when the function name was changed
from cri_sysicall3 to cr_syscall3.
For the unresolved symbol, it was some whitespace and I reran the make
as well.
I sent the cr_arch.h in a separate e-mail.
For the undefined reference of current_thread_info_reg, this is the
output of the build directory when I ran
$ nm cr_module/kbuild/*.o | grep -e ^cr_ -e current_thread_info_reg
cr_module/kbuild/blcr.mod.o:
U current_thread_info_reg
cr_module/kbuild/blcr.o:
U current_thread_info_reg
cr_module/kbuild/built-in.o:
cr_module/kbuild/cr_async.o:
U current_thread_info_reg
cr_module/kbuild/cr_barrier.o:
U current_thread_info_reg
cr_module/kbuild/cr_chkpt_req.o:
U current_thread_info_reg
cr_module/kbuild/cr_compat.o:
U current_thread_info_reg
cr_module/kbuild/cr_dest_file.o:
U current_thread_info_reg
cr_module/kbuild/cr_dump_self.o:
U current_thread_info_reg
cr_module/kbuild/cr_fops.o:
U current_thread_info_reg
cr_module/kbuild/cr_io.o:
U current_thread_info_reg
cr_module/kbuild/cr_ktrace.o:
U current_thread_info_reg
cr_module/kbuild/cr_mmaps.o:
U current_thread_info_reg
cr_module/kbuild/cr_module.o:
U current_thread_info_reg
cr_module/kbuild/cr_objects.o:
U current_thread_info_reg
cr_module/kbuild/cr_pipes.o:
U current_thread_info_reg
cr_module/kbuild/cr_proc.o:
U current_thread_info_reg
cr_module/kbuild/cr_relocate.o:
U current_thread_info_reg
cr_module/kbuild/cr_rstrt_req.o:
U current_thread_info_reg
cr_module/kbuild/cr_sync.o:
U current_thread_info_reg
cr_module/kbuild/cr_task.o:
U current_thread_info_reg
cr_module/kbuild/cr_timers.o:
U current_thread_info_reg
cr_module/kbuild/cr_trigger.o:
U current_thread_info_reg
cr_module/kbuild/cr_vmadump.o:
U current_thread_info_reg
cr_module/kbuild/cr_watchdog.o:
U current_thread_info_reg
After patching mem_map_zero and the depmod line, here are the errors
that I received:
if test -n "_depmod"; then /usr/bin/make _depmod; fi
make[3]: Entering directory `/opt/blcr-0.7.3_vincent/builddir'
ERROR: 'depmod' check FAILED (rc=1)
cr_depmod: current_thread_info_reg unresolved in blcr.ko
cr_depmod: mem_map_zero unresolved in blcr_vmadump.ko
make[3]: *** [_depmod] Error 1
make[3]: Leaving directory `/opt/blcr-0.7.3_vincent/builddir'
make[2]: *** [all-local] Error 2
make[2]: Leaving directory `/opt/blcr-0.7.3_vincent/builddir'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/opt/blcr-0.7.3_vincent/builddir'
make: *** [all] Error 2
It appears now the unresolved symbols appear, however mem_map_zero is
still shown as unresolved.
Thank you.
--
Vincentius Robby
Quoting "Paul H. Hargrove" <PHHargrove_at_lbl_dot_gov>:
>
> I would NOT ignore these. We should have all the proper casts in
> place, and no other architecture produces these warnings (at least
> not with any of the gcc versions I use). I am not sure of the cause
> w/o seeing exactly what you now have for cri_syscall3() and all the
> other macros it depends upon. The problem is that "line 170" is
> going to expand into >8 lines of code when the preprocessor does
> macro expansion (1 very long line, actually, due to the \ chars).
>
> Could you please send me your entire cr_arch.h file to
> PHHargrove_at_lbl_dot_gov (not the the checkpoint_at_lbl_dot_gov list address)_dot_ I
> don't have a SPARC/Linux machine, but I can pass it through the gcc
> on a SPARC/Solaris machine I have access to (or install a cross
> compiler from emdebian on an x86/Linux host). That should allow me
> to narrow down the problem, which is probably something silly.
>>
> I did not intend "cri_sysicall3", "cri_syscall3" is correct. Am I
> correct in understading that all the errors reported for cr_omit.c
> go away when cri_sysicall3 is corrected to cri_syscall3?
>
>
> The new errors are just because the build has advanced to the next
> step (previously unreachable because make stopped after the errors
> building the libraries).
>
>
> These are almost certainly SPARC-specific kernel symbols for which
> we'll need to add autoconf magic in configure.ac. I need to run to
> a meeting in a few minutes, but when I have a chance later today or
> tomorrow, I'll send you the lines to add. If you want to try on
> your own in the meantime, you are looking to add CR_FIND_KSYM()
> lines for eachof the unresolved symbols.
>
> I am slightly concerned by the line that reads
> "cr_depmod: unresolved in blcr.ko"
> Is that correct - only whitespace between the ":" and "unresolved"?
> If so there is probably something to fix in the contrib/cr_depmod
> perl script.
>
>
> The glibc-2.6 code that I was using for SPARC/Linux syscall ABI
> reference appears to contain an inconsistent mix of both __asm and
> __asm__, not only in the sparc code, but in ia64 as well. At least
> for now, my suggestion to you is to keep what you have until you
> encounter a compiler that refuses to accept it. Then, and only
> then, would I recommend trying to determine how to satisfy both that
> compiler and the one(s) presently in use.
>
> So, the TO DO list:
>
> 1) You should send me the cr_arch.h (to PHHargrove_at_lbl_dot_gov, not by
> reply) so I can search for the cause of "warning: initialization
> makes integer from pointer without a cast". In that e-mail, please
> also send the output of "gcc --version".
>
> 2) I will send, when I have time, the CR_FIND_KSYM() lines to add to
> configure.ac to deal with the (non-empty) unresolved kernel symbols
> (unless you e-mail to say you beat me to it).
>
> 3) If you can confirm the unresolved symbol message that contains
> only whitespace, I'd appreciate knowing if I need to mess with
> SPARC-specific mods to cr_depmod or not. We won't get past the
> depmod check until we do *something*.
>
> -Paul
>
> --
> Paul H. Hargrove PHHargrove_at_lbl_dot_gov
> Future Technologies Group
> HPC Research Department Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>
>
>
>