> Hello Everybody,
>
> we are teaching a class on Operating Systems at
> Dartmouth and we came across a strange
> behavior we can not find an explanation to. I forward
> here what Sean Smith has found so far:
>
> When playing around in class with memory faults and
> dtrace, we noticed something interesting:
> the address passed to trap is similar to but not the
> same as the faulting address.
> E.g., if I touch illegal address 0x00113738, we get a
> trap on 0x001131DE. Poking around in the
> code reveals:
>
>
> ttp://src.opensolaris.org/source/xref/onnv/onnv-gate/u
> sr/src/uts/sun4u/sys/mmu.h,
>
>
> 58 #define MMU_TAG_ACCESS 0x30 /* tlb
> tag access */
>
> 123 /*
> 124 * MMU TAG ACCESS register Layout
> 125 *
> 126 *
> +-------------------------+------------------+
> 127 * | virtual address [63:13] | context
> [12:0] |
> 128 *
> +-------------------------+------------------+
> 129 * 63 13 12
> 0
>
> 131 #define TAGACC_CTX_MASK 0x1FFF
> 132 #define TAGACC_SHIFT 13
> 133 #define TAGACC_VADDR_MASK
> (~TAGACC_CTX_MASK)
> 4 #define TAGACC_CTX_LSHIFT (64 -
> TAGACC_SHIFT)
>
> All well and code: the strangeness in the low-order
> part of the trap address must be this
> "context."
> This is confirmed by seeing that
> sfmmu_tsbmiss_exception is getting called before,
> with a
> "tagaccess" arg of 0x001131DE.
>
> However....
>
> where''s this context of "0x11DE" coming from? The
> ASI for this process is 0x82!
>
> Is anybody familiar with this piece of code ?
>
> Later,
> Max & Sean
Not an answer, but note that 2^13 (bits 0 through 12) is 8192,
which also happens to be the smallest page size that Solaris
supports, AFAIK. Which is to say the smallest resolution in general
for determining what if any access to a memory address will be permitted
is a page.
I also just noticed that the siginfo(3head) man page says:
> For some implementations, the exact value of si_addr may not be
> available; in that case, si_addr is guaranteed to be on the same page
> as the faulting instruction or memory reference.
FWIW, I just wrote a simple C program to cause a SEGV by doing something
like
*((char *) 1) = ''\0'';
and the si_addr field of 2nd parameter to the handler (set using sigaction(2)
with the SA_SIGINFO flag) was indeed 1. So at least sometimes the result
_is_ exact. (this was on SPARC)
There are of course situations where an exact address is desirable,
but I doubt that for debugging it would usually matter all that much where
a bad pointer was pointing to, rather just that it was a fault and what the
page was.
While one can''t _depend_ on an exact fault address being available, I
suppose it would be nice to know in what situations it was and wasn''t
exact, and as in your case, just what (if anything) the low-order bits
represented when it wasn''t exact.
--
This message posted from opensolaris.org