[PATCH] D91617: [sanitizer_common][test] Disable CompactRingBuffer.int64 on Solaris/sparcv9

Wed Nov 18 06:58:48 PST 2020

ro added a comment.

In D91617#2401121 <https://reviews.llvm.org/D91617#2401121>, @eugenis wrote:

> Does it mean CompactRingBuffer is broken, or just the test?

Hard for me to tell given that this is the only test using it. Besides, hwasan is the only user which isn't supported on SPARC, so I didn't look at the test very hard.

> Is this ADI? I don't understand why bits 52-56 (and below) are 0xff in your example.

No, while the machine I use for my tests (a Netra SPARC S7-2) is ADI-capable, it needs to be enabled explicitly.

When I look at the processes' address space with `pmap -x`, I find (among many others)

  [...]
  FFFFFFFF7F59A000     16     -     -    - rw-----  [ anon ]

while the faulting address is

  mapping	        FFFFFFFF7F59A000
  next		  ffffff7f59a000

i.e. 8 bits masked.

> Could you tell me more about the 64-bit address space in solaris/sparcv9?

The layout can be seen here <https://docs.oracle.com/cd/E37838_01/html/E66175/advanced-2.html#SSFDGadvanced-5>.  There's a large virtual address hole in the middle, the exact location of which cannot be determined programmatically (yet) and depends on the exact hardware used.  This obviously creates problems for a future Solaris/sparcv9 ASan port, too.  Solaris/amd64 used to be the same, but they changed the layout during the large-scale rewrite of the VM system in Solaris 11.2.

> Would it work to
>
> - mask off the top bits of "storage" in Init
> - somehow disable tag checking when storing through the truncated pointer?

I can't tell for certain, but at first blush it doesn't look like it would.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D91617/new/

https://reviews.llvm.org/D91617