RFR: 8253167: ARM32 builds fail after JDK-8247910

[Boris Ulasevich]

Hi,

Yes, the change is Ok.
It will fix JDK-8213483 by the way.
Thanks for doing this!

regards,
Boris

On Sat, Sep 19, 2020 at 12:07 AM Kim Barrett <kbarrett at openjdk.java.net> wrote:
>
> Please review this fix for a build failure for arm32.
>
> nconstexpr functions cannot contain asm statements (until C++20), even if
> not executed by a constexpr invocation. This means assert (for example)
> can't be used in a constexpr function on arm32, because of the
> implementation of the BREAKPOINT macro as an asm statement for linux-arm.
>
> The current arm32 implementation is from JDK-8077648: "ARM: BREAKPOINT is
> wrong for thumb", which is a Confidential bug about Oracle's old closed
> source arm32 port. That port was open sourced by JDK-8168503: "JEP 297:
> Unified arm32/arm64 Port". The discussion of JDK-8077648 suggested making
> the arm32 port be like nearly all others. That is, have BREAKPOINT expand to
> a call to ::breakpoint(), with any empty body for that function and a
> comment that one should use a debugger to set a breakpoint there.
>
> This change takes that alternative approach.
>
> The same problem likely exists for win32, which also implements BREAKPOINT
> as an asm statement. However, I don't have the infrastructure to do a win32
> build to demonstrate that. But I'm making a similar change there on spec.
>
> Note that the Windows implementation of ::breakpoint() ultimately calls the
> DebugBreak Win32 library function. That should work for the windows-x86 port
> too.
>
> I don't know why we have that difference of some platforms having an
> affirmative platform-specific breakpoint operation in place while others
> require a debugger to set one, but that difference already exists. This
> change does move arm32 from the former to the latter camp though. I'm
> guessing that won't matter; if it does then we'll need to conditionalize the
> body of ::breakpoint().
>
> There may be some further cleanup that could be done after this change.
> We don't really need the BREAKPOINT macro anymore, and could just
> use ::breakpoint() directly.  But I think that's out of scope for dealing
> with the build failure(s).
>
> Testing:
> build linux-arm.
> tier1 for Oracle supported platforms.
>
> -------------
>
> Commit messages:
>  - remove BREAKPOINT variants
>
> Changes: https://git.openjdk.java.net/jdk/pull/259/files
>  Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=259&range=00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8253167
>   Stats: 19 lines in 2 files changed: 0 ins; 18 del; 1 mod
>   Patch: https://git.openjdk.java.net/jdk/pull/259.diff
>   Fetch: git fetch https://git.openjdk.java.net/jdk pull/259/head:pull/259
>
> PR: https://git.openjdk.java.net/jdk/pull/259