[RFR] Re: jdk9 builds status

Anton Kozlov akozlov at azul.com
Mon May 30 15:30:56 UTC 2016 

Hi, Alex,

Thanks for finding this and the fix!
 
The %function flag should matter in case both C and asm code was
compiled with thumb option.  As far as I understand, without the flag,
function symbol just points to a memory, at first byte of instructon.
This is OK for arm, but incorrect for thumb, there it should be ORed
with 1 to tell the core "thumb instruction set used in the function".
Without it, thumb mode will be switched to arm on call, and this is
fatal for thumb callee.

Probably your compilers select different instruction sets by default,
seems like gcc6 is ARM and gcc5 is thumb.

Another option is to force arm mode by passing -marm gcc option in
*FLAGS. But I'd prefer your fix.

Thanks,
Anton

On Mon, 2016-05-30 at 15:23 +0100, Alex Kashchenko wrote:
> Hi,
> 
> On 05/27/2016 02:48 PM, Alex Kashchenko wrote:
> > 
> > Hi Andrey and Anton,
> > 
> > Thanks for detailed explanation. Your change works for me with
> > jdk8. I
> > haven't yet tried it with jdk9 - I will write back into this thread
> > if
> > I'll met problems with jdk9.
> I've done some more testing, this change works fine with GCC 6 (gcc 
> (GCC) 6.1.1 20160510 (Red Hat 6.1.1-2)) but breaks for me with GCC 5 
> (gcc (Ubuntu/Linaro 5.3.1-14ubuntu2) 5.3.1 20160413). With GCC 5 it 
> steps from os::current_stack_pointer into 
> linux_aarch32_current_frame_pointer but refuses to return on "bx lr"
> - 
> keeps going through memory and crashes soon.
> 
> As I understand, this is somehow related to asm-defined symbol type. 
> After I marked asm function with ".type %function" - it works
> correctly 
> with GCC 5. The full asm code that worked for me with slowdebug
> builds 
> of jdk8u and jdk9:
> 
> .global linux_aarch32_current_frame_pointer
> .type linux_aarch32_current_frame_pointer,%function
> linux_aarch32_current_frame_pointer:
>    mov r0, sp
>    bx lr
> 
> Currently doing full rebuild of jdk8 on GCC 6 and jdk9 on GCC 5 -
> will 
> report back if I'll find any problems.
> 
> > 
> > 
> > On 05/26/2016 06:57 PM, Anton Kozlov wrote:
> > > 
> > > Hi, All!
> > > 
> > > As Andrey said, we reworked current_stack_pointer next way:
> > > 
> > > === Patch begin ===
> > > diff -r 79bf1547b28d -r c4f98cfc8c40
> > > src/os_cpu/linux_aarch32/vm/asm_os_linux_aarch32.s
> > > --- /dev/null   Thu Jan 01 00:00:00 1970 +0000
> > > +++
> > > b/src/os_cpu/linux_aarch32/vm/asm_os_linux_aarch32.s        Thu
> > > May
> > > 26 18:26:08 2016 +0300
> > > @@ -0,0 +1,5 @@
> > > +
> > > +.global linux_aarch32_current_frame_pointer
> > > +linux_aarch32_current_frame_pointer:
> > > +  mov r0, sp
> > > +  bx lr
> > > diff -r 79bf1547b28d -r c4f98cfc8c40
> > > src/os_cpu/linux_aarch32/vm/os_linux_aarch32.cpp
> > > --- a/src/os_cpu/linux_aarch32/vm/os_linux_aarch32.cpp  Sat May
> > > 14
> > > 17:34:57 2016 +0100
> > > +++ b/src/os_cpu/linux_aarch32/vm/os_linux_aarch32.cpp  Thu May
> > > 26
> > > 18:26:08 2016 +0300
> > > @@ -81,10 +81,12 @@
> > >   #define SPELL_REG_SP "sp"
> > >   #define SPELL_REG_FP "fp"
> > > 
> > > +extern "C" {
> > > +  void *linux_aarch32_current_frame_pointer();
> > > +}
> > > +
> > >   address os::current_stack_pointer() {
> > > -  register void* sp __asm__ (SPELL_REG_SP);
> > > -  // This is a leaf method. Only rfp has been pushed.
> > > -  return (address) sp + BytesPerWord;
> > > +  return (address) linux_aarch32_current_frame_pointer();
> > >   }
> > > 
> > >   char* os::non_memory_address_word() {
> > > 
> > > === Patch end ===
> > > 
> > > Current version had next issue. ARM requires stack alignment to
> > > be 8 on
> > > "external interfaces" (on calls to functions in another
> > > compilation
> > > modules, for example). This is achived by making stack pointer 8-
> > > aligned initialy and maintaining all stack frames to be 8-
> > > aligned.
> > > JVM is checking the alignement in numerous asserts around the
> > > code by
> > > calling os::current_stack_pointer, which is therefore required to
> > > return 8byte-aligned value.
> > > However, in current implementation, sp in the middle of
> > > os::current_stack_pointer is not on caught by "external
> > > enterface"
> > > constraint, so compiler is free to make arbitrary stack frame for
> > > the
> > > function, which happened to be one word frame (for fp). So we are
> > > forced to assume compiler's frame size and adjust sp.
> > > 
> > > I suspect that after removing one-word adjustment (Alex's change)
> > > jvm
> > > should fail in slowdebug mode with "unaligned" message, at least
> > > it
> > > failed so under my system (raspberry-pi2, raspbian, raspbian
> > > compiler)
> > > in previous.
> > > 
> > > Suggested implementation is not affected by this, compiler should
> > > maintain 8byte-aligned frame size before making a call to asm
> > > helper
> > > functon. Note, that 8-aligned frame size doesn't make jvm
> > > alignment
> > > checks useless, since if sp alignment broke deeper in stack, it
> > > will
> > > remain unaligned till the top.
> > > 
> > > Thanks,
> > > Anton
> > > 
> > > On Thu, 2016-05-26 at 12:56 +0000, Andrey Petushkov wrote:
> > > > 
> > > > Dear Alex,
> > > > 
> > > > pardon for the delayed response. Actually we've reworked the
> > > > the code
> > > > which
> > > > exhibits this problem, because we've found it's not robust vs
> > > > different
> > > > toolchains and compilation options. So finally we're using pure
> > > > assembler
> > > > to obtain the value of the stack pointer. We'll soon publish
> > > > the
> > > > respective
> > > > changeset
> > > > 
> > > > Regards,
> > > > Andrey
> > > > 
> > > > On Wed, May 25, 2016 at 5:41 PM Alex Kashchenko <akashche at redha
> > > > t.com>
> > > > wrote:
> > > > 
> > > > > 
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > I found that jdk9 in http://hg.openjdk.java.net/aarch32-port/
> > > > > jdk9/
> > > > > is
> > > > > broken after the "pre C1" commit due to this discrepancy:
> > > > > 
> > > > >    - jdk8u:
> > > > > 
> > > > > http://hg.openjdk.java.net/aarch32-port/jdk8u/hotspot/rev/b3e
> > > > > 996878
> > > > > ddf#l35.6
> > > > >    - jdk9:
> > > > > http://hg.openjdk.java.net/aarch32-port/jdk9/hotspot/rev/52d2
> > > > > 92d5c1
> > > > > 2f#l35.7
> > > > > 
> > > > > "fp" register is zero at that point and vm crashes on
> > > > > startup.
> > > > > 
> > > > > With the following change:
> > > > > 
> > > > >    address os::current_stack_pointer()  {
> > > > > -  register void* fp __asm__ (SPELL_REG_FP);
> > > > > +  register void* sp __asm__ (SPELL_REG_SP);
> > > > >      // Only lr on top of fp
> > > > > -  return (address) fp + BytesPerWord;
> > > > > +  return (address) sp;
> > > > >    }
> > > > > 
> > > > > jdk9 works and can bootstrap itself - I've built slowdebug
> > > > > jdk9
> > > > > using a
> > > > > fastdebug one as a boot jdk.
> > > > > 
> > > > > This is just a "heads up" - I am not proposing to integrate
> > > > > this
> > > > > change,
> > > > > as it differs from jdk8u and initial change in that place
> > > > > (linked
> > > > > above)
> > > > > probably has been done for the reason.
> > > > > 
> > > > > PS: additional question on aarch32-jdk9 plans: as upstream
> > > > > jdk9 is
> > > > > feature complete now, does it make sense to update aarch32-
> > > > > jdk9
> > > > > forest
> > > > > from it or is it better to wait for some point closer to jdk9
> > > > > release?
> > > > > 
> > > > > --
> > > > > -Alex
> > 
>

More information about the aarch32-port-dev mailing list