Resolve some disagreements between SIMARM and XARM on offsets used in compiled code.

Resolve some disagreements between SIMARM and XARM on offsets used in compiled code.

gcc ia32 (SIMARM) seems to prefer to pack structures whereas gcc arm (XARM) seems to prefer to keeping things aligned.

R=fschneider@google.com

Committed: https://github.com/dart-lang/sdk/commit/5dc51af924b9d3cb1005a530fe95dc1663b1eb53

[rmacnak, 2015-09-18 23:56:32]

rmacnak@google.com changed reviewers:
+ iposva@google.com

[rmacnak, 2015-09-24 20:30:56]

Patchset #2 (id:20001) has been deleted

[rmacnak, 2015-09-29 23:37:36]

rmacnak@google.com changed reviewers:
+ fschneider@google.com

[rmacnak, 2015-09-29 23:37:36]

+Florian

[Florian Schneider, 2015-09-30 09:38:13]

lgtm

https://codereview.chromium.org/1351403004/diff/1/runtime/vm/heap.h
File runtime/vm/heap.h (right):

https://codereview.chromium.org/1351403004/diff/1/runtime/vm/heap.h#newcode317
runtime/vm/heap.h:317: Isolate* isolate_;

This seems still fragile, since there are members of Scavenger that may be
packed differently. I think we would need to add ALIGNx to all those as well to
be sure that isolate_ is at the same offset.

Maybe add a COMPILE_ASSERT for 32 and 64 bit to be sure it does not break.

https://codereview.chromium.org/1351403004/diff/1/runtime/vm/isolate.h
File runtime/vm/isolate.h (right):

https://codereview.chromium.org/1351403004/diff/1/runtime/vm/isolate.h#newcod...
runtime/vm/isolate.h:820: uword stack_limit_;
Add a COMPILE_ASSERT at for the first member, and maybe ALIGNx for the others to
make sure the offsets are consistent across compilers.

[rmacnak, 2015-10-01 22:00:50]

Of course, this isn't comprehensive, but it's enough to precompile simple
programs with simarm and run them on a Pi.

https://codereview.chromium.org/1351403004/diff/1/runtime/vm/heap.h
File runtime/vm/heap.h (right):

https://codereview.chromium.org/1351403004/diff/1/runtime/vm/heap.h#newcode317
runtime/vm/heap.h:317: Isolate* isolate_;
On 2015/09/30 09:38:13, Florian Schneider wrote:
> 
> This seems still fragile, since there are members of Scavenger that may be
> packed differently. I think we would need to add ALIGNx to all those as well
to
> be sure that isolate_ is at the same offset.

This is to get Heap::Top/EndOffset(kNew) consistent. We shouldn't be using
isolate_ or anything below.

https://codereview.chromium.org/1351403004/diff/1/runtime/vm/isolate.h
File runtime/vm/isolate.h (right):

https://codereview.chromium.org/1351403004/diff/1/runtime/vm/isolate.h#newcod...
runtime/vm/isolate.h:820: uword stack_limit_;
On 2015/09/30 09:38:13, Florian Schneider wrote:
> Add a COMPILE_ASSERT at for the first member, and maybe ALIGNx for the others
to
> make sure the offsets are consistent across compilers.

The compiler won't allow use of OFFSET_OF in a COMPILE_ASSERT.

runtime/vm/globals.h:54:69: error: a cast to a type other than an integral or
enumeration type cannot appear in a constant-expression
   (reinterpret_cast<intptr_t>(&(reinterpret_cast<type*>(kOffsetOfPtr)->field))

[rmacnak, 2015-10-01 22:01:25]

Committed patchset #1 (id:1) manually as
5dc51af924b9d3cb1005a530fe95dc1663b1eb53 (presubmit successful).

[Florian Schneider, 2015-10-02 13:41:09]

https://codereview.chromium.org/1351403004/diff/1/runtime/vm/isolate.h
File runtime/vm/isolate.h (right):

https://codereview.chromium.org/1351403004/diff/1/runtime/vm/isolate.h#newcod...
runtime/vm/isolate.h:820: uword stack_limit_;
On 2015/10/01 22:00:49, rmacnak wrote:
> On 2015/09/30 09:38:13, Florian Schneider wrote:
> > Add a COMPILE_ASSERT at for the first member, and maybe ALIGNx for the
others
> to
> > make sure the offsets are consistent across compilers.
> 
> The compiler won't allow use of OFFSET_OF in a COMPILE_ASSERT.
> 
> runtime/vm/globals.h:54:69: error: a cast to a type other than an integral or
> enumeration type cannot appear in a constant-expression
>   
(reinterpret_cast<intptr_t>(&(reinterpret_cast<type*>(kOffsetOfPtr)->field))

gcc has the offsetof macro which can appear as compile-time constant - Not sure
about MSVC, but the problem you're fixing here affects gcc, so we could use it
here under an #ifdef.