Re: sparc implementation

From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Thu Sep 04 2008 - 14:18:55 PDT

  • Next message: Paul H. Hargrove: "Re: sparc implementation"
    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   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 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 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

  • Next message: Paul H. Hargrove: "Re: sparc implementation"