From: Vincentius Robby (vincentius_at_umich_dot_edu)
Date: Tue Sep 02 2008 - 12:38:03 PDT
Hello,
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
>
>
>
>