Re: [Boost-bugs] [Boost C++ Libraries] #8993: boost_1_54_0 bootstrap broken on m68k-linux due to alignment mistakes

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #8993: boost_1_54_0 bootstrap broken on m68k-linux due to alignment mistakes
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2013-08-14 07:54:00

#8993: boost_1_54_0 bootstrap broken on m68k-linux due to alignment mistakes
------------------------------------------+----------------------------
  Reporter:  Mikael Pettersson <mikpe@…>  |      Owner:
      Type:  Bugs                         |     Status:  new
 Milestone:  To Be Determined             |  Component:  Building Boost
   Version:  Boost 1.54.0                 |   Severity:  Showstopper
Resolution:                               |   Keywords:
------------------------------------------+----------------------------

Comment (by Mikael Pettersson <mikpe@…>):

 Originally reported at Debian <http://bugs.debian.org/cgi-

 bin/bugreport.cgi?bug=719484>.

 Attempting to bootstrap boost_1_54_0 on m68k-linux fails early on with an
 assertion failure in tools/build/v2/engine/function.c:

 ../bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root= clean
 jam0: function.c:233: check_alignment: Assertion `(size_t)s->data %
 sizeof( LIST * ) == 0' failed.
 Aborted

 With additional debugging added to that file, I observed that the stack
 went out of alignment in a stack_allocate call from expand_modifiers line
 857, which allocated a multiple of sizeof(VAR_EDIT).  However,
 sizeof(VAR_EDIT) is NOT a multiple of sizeof(LIST*) on m68k-linux, so the
 assertion triggered.

 The thing to know about m68k on Linux is that it has more relaxed
 alignment rules than most machines.
 In this case, even though VAR_EDIT contains some uint32_t-sized fields
 (pointers and ints) plus 6 plain char fields, its size ends up being
 k*sizeof(uint32_t) [for the embedded pointer and int fields] + 6, with no
 additional padding, which isn't a multiple of sizeof(LIST*).

 Assuming the sizeof(LIST*) alignment assertion actually is needed, the
 obvious solution is to ensure that (a) the stack end is aligned when
 initially allocated, and (b) affected allocation sites pad their
 allocations to a multiple of the alignment requirement (and likewise for
 the deallocation sites).

 During a complete build I couldn't find any other issues than the ones
 already mentioned (inital stack alignment, sizeof(VAR_EDIT)), so this
 patch only addresses those specific sites.  There are other sites that
 allocate or deallocate data that isn't necessarily a multiple of
 sizeof(LIST*), but none of those triggered assertion failures during my
 build, so I'm leaving them alone.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/8993#comment:1>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.