From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Thu Sep 04 2008 - 14:18:55 PDT
Vincentius Robby wrote:
> Hello Paul,
>
> Thanks for that, seems like I missed it somewhere.
> For the predefined variables (CRI_*), it appears that it generated
> this warning:
> ../../libcr/cr_syscall.c: In function '__cri_ioctl':
> ../../libcr/cr_syscall.c:169: warning: initialization makes integer
> from pointer without a cast
> ../../libcr/cr_syscall.c: In function '__cri_open':
> ../../libcr/cr_syscall.c:170: warning: initialization makes integer
> from pointer without a cast
> ..
> etc.
>
> Is it safe to ignore these?
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 also encountered another error, which is shown below:
> ../../libcr/cr_omit.c:57: error: expected declaration specifiers or
> '...' before 'crsig_ioctl'
> ../../libcr/cr_omit.c:57: error: expected declaration specifiers or
> '...' before '__NR_ioctl'
> ../../libcr/cr_omit.c:58: warning: return type defaults to 'int'
> ../../libcr/cr_omit.c: In function 'cri_sysicall3':
> ../../libcr/cr_omit.c:59: error: expected '=', ',', ';', 'asm' or
> '__attribute__' before '{' token
> ../../libcr/cr_omit.c:57: error: parameter name omitted
> ../../libcr/cr_omit.c:57: error: parameter name omitted
> ../../libcr/cr_omit.c:57: error: parameter name omitted
> ../../libcr/cr_omit.c:57: error: parameter name omitted
> ../../libcr/cr_omit.c:94: error: expected '{' at end of input
> make[2]: *** [libcr_la-cr_omit.lo] Error 1
>
> Was the cri_sysicall3 intended instead of cri_syscall3?
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?
> When I changed it, I got the following new errors:
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).
> make[3]: Entering directory `/opt/blcr-0.7.3_vincent/builddir'
> ERROR: 'depmod' check FAILED (rc=1)
> cr_depmod: unresolved in blcr.ko
> 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
>
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.
> I tried make clean and ran make again with the same results.
> And even though make ran until that point, on the cri_syscallx
> functions, am I supposed to use __asm__ instead of __asm? Currently
> the code in my copy has __asm and so does the glibc code while
> cr_arch.h of other architectures under BLCR uses __asm__.
>
> Thank you.
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