Re: sparc implementation

From: Vincentius Robby (vincentius_at_umich_dot_edu)
Date: Fri Sep 05 2008 - 08:59:11 PDT

  • Next message: Vincentius Robby: "Re: sparc implementation"
    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
                      U current_thread_info_reg
                      U current_thread_info_reg
                      U current_thread_info_reg
                      U current_thread_info_reg
                      U current_thread_info_reg
                      U current_thread_info_reg
                      U current_thread_info_reg
                      U current_thread_info_reg
                      U current_thread_info_reg
                      U current_thread_info_reg
                      U current_thread_info_reg
                      U current_thread_info_reg
                      U current_thread_info_reg
                      U current_thread_info_reg
                      U current_thread_info_reg
                      U current_thread_info_reg
                      U current_thread_info_reg
                      U current_thread_info_reg
                      U current_thread_info_reg
                      U current_thread_info_reg
                      U current_thread_info_reg
                      U current_thread_info_reg
                      U current_thread_info_reg
                      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   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  
    > 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

  • Next message: Vincentius Robby: "Re: sparc implementation"