On Sat, Nov 6, 2010 at 5:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> As I said above, I don't know of any good way to measure register stack
> depth directly. It's probably possible to find out by asking the kernel
> or something like that, but we surely do not want to introduce a kernel
> call into check_stack_depth().
It seems more likely it would be some kind of asm than a trap. This
might be wishful thinking but is it too much to hope that glibc
already exposes it through some function?
It looks like the relevant registers are ar.bsp and ar.bspstore. Just
taking the difference apparently gives you the amount of memory used
in the current backing store.
However some of the comments I'm reading seem to imply that the OS can
allocate discontiguous backing store partitions, presumably if the
backing store pointer reaches an unmapped address there has to be some
way to trap to the OS to allocate more and maybe then it has a chance
to tweak the bsp address?
This was quite interesting (especially the "The Register Stack Engine"
section of the second one):
http://msdn.microsoft.com/en-us/magazine/cc301708.aspx
http://msdn.microsoft.com/en-us/magazine/cc301711.aspx
Also I found the following:
(lists some registers)
http://www.cs.clemson.edu/~mark/subroutines/itanium.html
(helper functions in glibc asm includes that calculate bspstore-bsp to
count the number of registers used)
http://www.koders.com/c/fidE15CABBBA63E7C24928D7F7C9A95653D101451D2.aspx?s=queue
Also I found http://www.nongnu.org/libunwind/man/libunwind(3).html
which I found cool though not really relevant. The ia64 implementation
fiddles with the RSE registers as well of course.
--
greg