Re: sparc implementation

From: Vincentius Robby (vincentius_at_umich_dot_edu)
Date: Tue Sep 02 2008 - 12:38:03 PDT

  • Next message: Paul H. Hargrove: "Re: sparc implementation"
    I have a small particular question about sparc stack pointers.
    In cr_module/arch/*/cr_arch.h, for different architecture there seems  
    to be different methods of obtaining the stack pointers, such as  
    regs->sp (i386), regs->gpr[1] (ppc), and regs->ARM_sp (arm). Is there  
    a different method for sparc to obtain the stack pointer?  
    regs->sp/regs->o6 does not seem to solve it.
    Thank you.
    Vincentius Robby
    Quoting "Paul H. Hargrove" <PHHargrove_at_lbl_dot_gov>:
    > In both the BLCR kernel and user-space code we make use of atomic  
    > counters for various purposes, including a reader-writer sort of  
    > lock in the user space code.  In all architectures we've supported  
    > so far we've had support for atomic operations on 32-bit integers.   
    > However, on SPARC revisions prior to "SPARC V8+" (UltraSPARC) the  
    > only support for atomics is via spinlocks.  The spinlock approach  
    > can work in the kernel because one can block interrupts.  In  
    > user-space, however, the spinlock approach can lead to deadlock in  
    > the presence of signal handlers.  So, I believe that it is either  
    > impossible or impractical to port BLCR to chips older than  
    > UltraSPARC. (I am willing to be proven wrong, but am strongly  
    > discouraging you from trying for older cpus as I think success is  
    > unlikely)
    > Except for the atomic-ops issue above, I am not aware of a "major  
    > hindrance" for a SPARC port of BLCR, but we don't have the resources  
    > (either people time or machines) to do it ourselves.  For somebody  
    > with understanding of the SPARC platform (including ASM and ABI  
    > issues), we should be able to provide the guidance to perform a port.
    > The "vmadump" directory contains support only for 2.4.X kernels, and  
    > is being dropped from BLCR (kept only for RH9 and RHEL kernels in  
    > blcr-0.7.X and will be removed entirely by the time 0.8.X is  
    > released).  The original BProc/VMADump code did support SPARC,  
    > though I have no idea if that was well tested or not.  When  
    > BProc/VMADump was ported to the 2.6.X kernels, the SPARC platform  
    > code was apparently not ported.  This was most likely due to a  
    > combination of lack of time and lack of interest.
    > The steps for a BLCR port are:
    > 1) vmadump4/vmadump_<ARCH>.c, with additions to vmadump.h if needed.
    >    This should hopefully just be a straight-forward port of the  
    > older vmadump code.  However, the 2.4.x vs. 2.6.x differences may be  
    > non-trivial.  Additionally, BLCR supports pthreads, which the  
    > original VMADump did not, and this requires that the ABI's  
    > thread-specific data pointers be dealt wth properly, which the  
    > exisiting VMADump code might not do.
    > 2) include/blcr_ksyms.h needs the right inline ASM bits for linker info
    > 3) cr_module/arch/<ARCH>/cr_arch.h needs a couple of inline  
    > functions which can probably be found in the vmadump code.
    > 4) libcr/arch/<ARCH>/cr_{arch,atomic}.h needs inline ASM for system  
    > calls and atomic operations, plus ASM for a simple signal handler.   
    > All these things should be present in glibc's source code somewhere.  
    >  DO NOT cut-and-paste any of this stuff from the Linux kernel (the  
    > kernel is GPL and the code in libcr is LGPL)
    > Without knowing your own level if familiarity with the SPARC  
    > platform, I cannot estimate the time this port would take.  However,  
    > I can say that I will be available to provide some guidance with the  
    > various inline ASM pieces.
    > -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: Paul H. Hargrove: "Re: sparc implementation"