StubRoutines::load_long_atomic causes SIGBUS on aarch32

[Boris Ulasevich]

Let's clarify. You have a SIGBUS error on ldrexd r0, [r0] 
atomic_load_long stub, "ldrexd r0, [r0]" instruction, because r0 
(actually it is pointer to InstanceKlass::_dep_context_last_cleared) is 
not 8-bytes aligned. Is that correct?

 > Version 6.3.0 (at /usr/bin/gcc)

Oh, you build OpenJDK on RPI itself! Ok.

 > I see uint64_t aligned at the 4 bytes boundary

That is strange.

Boris

On 10.01.2019 3:02, Sergei Ustimenko wrote:
> Hi again Boris,
> 
> Thanks for the link you've provided it appears to be so much useful!
> And sorry for confusion too: I was talking about the pointer [1] type
> which is 4 bytes aligned (as described in 4.1 Fundamental Data Types).
> 
> [1] - 
> http://hg.openjdk.java.net/jdk/jdk/file/32c6cc430526/src/hotspot/share/oops/instanceKlass.cpp#l2117
> 
> Thanks,
> Sergei
> 
> On Wed, 9 Jan 2019 at 12:56, Boris Ulasevich 
> <boris.ulasevich at bell-sw.com <mailto:boris.ulasevich at bell-sw.com>> wrote:
> 
>     Hi Sergei,
> 
>     On 31.12.2018 2:06, Sergei Ustimenko wrote:
>      > Hi Andrey,
>      >
>      > Sorry for keep you waiting. I've checked with the latest
>      > jdk12 and it yields the same result.
>      >
>      > I got to make myself clear on how I'm actually getting the
>      > java binaries in the first place. So I'm  building and running
>      > the test using the very same machine (armv7-a). Hotspot
>      > compilation is done using GCC. In my case
>      >
>      > uint64_t volatile InstanceKlass::_dep_context_last_cleared
>      >
>      > has word alignment and later in the
> 
>     What toolchain do you use to build jdk? ARM ABI states that 64-bit data
>     is 8-byte aligned.
>     http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0042f/index.html
> 
>      > DependencyContext::claim_cleanup
>      >
>      > causes the problem.
>      > So I've checked against jdk12 tip - same results,
>      > I wanted to check against jdk11 - and I have some problems of
>      > other sort. Though the cross-compiled jdk11 seems to work fine.
>      > I'm not entirely sure on that so I'll check.
>      >
>      > I just wonder if in the worst case the alignment would need to be
>      > changed, what would be the best option.
>      >
>      > Anyway, thanks for your time and advice.
>      >
>      > Cheers,
>      > Sergei
>      >
>      >
>      > On Sun, 30 Dec 2018 at 00:58, Andrey Petushkov
>     <andrey.petushkov at gmail.com <mailto:andrey.petushkov at gmail.com>>
>      > wrote:
>      >
>      >> hi Sergei,
>      >>
>      >> yes, this looks like it. and the reason I think it's that you
>     are using
>      >> Java 13 code base, which is quite far from release state. at the
>     same time
>      >> support for 32 bit platforms declines apparently, hence such
>     kind of bugs
>      >> are imminent. may I suggest you to try version 11 or at least 12
>     and check
>      >> whether the problem goes away?
>      >>
>      >> regards,
>      >> Andrey
>      >>
>      >> сб, 29 Дек 2018 г., 19:28 Sergei Ustimenko <merkel05 at gmail.com
>     <mailto:merkel05 at gmail.com>>:
>      >>
>      >>> Hi again,
>      >>>
>      >>> I had to mention that I've checked the reference manual on armv7-a
>      >>> and it says that address in the base register have to be doubleword
>      >>> aligned. Most likely that causes SIGBUS. Though I just wanted
>     to know
>      >>> if anyone faced that before and may provide some quick tips.
>      >>>
>      >>> Thanks,
>      >>> Sergei
>      >>>
>      >>> On Sat, 29 Dec 2018 at 17:01, Sergei Ustimenko
>     <merkel05 at gmail.com <mailto:merkel05 at gmail.com>>
>      >>> wrote:
>      >>>
>      >>>> Hi,
>      >>>>
>      >>>> Recently I've stumbled upon quite curious situation in the
>     aarch32 port.
>      >>>> I have latest raspberry pi 3b+ which has an armv8-a CPU, that
>     works
>      >>>> in the compatibility mode. Raspbian in that case shows me that CPU
>      >>>> is in the 32 bits mode and uses armv7-a instructions set.
>      >>>>
>      >>>> When I was building and testing the sandbox flavor of openjdk,
>     amongst
>      >>>> some tests that failed I've noticed an unusual one:
>      >>>>
>      >>>> TestAnonymousClassUnloading.java fails with:
>      >>>>
>      >>>> #  SIGBUS (0x7) at pc=0x73db4884, pid=5430, tid=5435
>      >>>> #
>      >>>> # JRE version: OpenJDK Runtime Environment (13.0) (build
>      >>>> 13-internal+0-adhoc.pi.sandbox)
>      >>>> # Java VM: OpenJDK Server VM (13-internal+0-adhoc.pi.sandbox,
>     mixed
>      >>> mode,
>      >>>> sharing, serial gc, linux-arm)
>      >>>> # Problematic frame:
>      >>>> # v  ~StubRoutines::atomic_load_long
>      >>>>
>      >>>> r0  = 0x5bde8e94
>      >>>> 0x5bde8e94 is pointing into metadata
>      >>>>
>      >>>> pc  = 0x73db4884
>      >>>> 0x73db4884 is at begin+4 in a stub
>      >>>> StubRoutines::atomic_load_long [0x73db4880, 0x73db488c[ (12 bytes)
>      >>>>
>      >>>> StubRoutines::atomic_load_long [0x73db4880, 0x73db488c[ (12
>      >>>> bytes)[Disassembling for mach='arm']
>      >>>>    0x73db4880: ldrexd    r0, [r0]
>      >>>>    0x73db4884: clrex
>      >>>>    0x73db4888: bx        lr
>      >>>> VM_Operation (0x643fe5f8): GenCollectFull, mode: safepoint,
>     requested by
>      >>>> thread 0x7609fc00
>      >>>>
>      >>>> Does anybody have any suggestion where I could read on why the
>     `clrex`
>      >>>> caused SIGBUS?
>      >>>>
>      >>>> Regards,
>      >>>> Sergei
>      >>>>
>      >>>
>      >>
>