Opened 9 years ago

Closed 8 years ago

#8993 closed Bugs (fixed)

boost_1_54_0 bootstrap broken on m68k-linux due to alignment mistakes

Reported by: Mikael Pettersson <mikpe@…> Owned by: Vladimir Prus
Milestone: To Be Determined Component: build
Version: Boost 1.54.0 Severity: Showstopper
Keywords: Cc:

Description


Attachments (1)

boost_1_54_0-m68k-1.patch (2.9 KB ) - added by Mikael Pettersson <mikpe@…> 9 years ago.
explicitly pad arrays of VAR_EDITs on the stack to a multiple of sizeof(LIST*)

Download all attachments as: .zip

Change History (4)

by Mikael Pettersson <mikpe@…>, 9 years ago

Attachment: boost_1_54_0-m68k-1.patch added

explicitly pad arrays of VAR_EDITs on the stack to a multiple of sizeof(LIST*)

comment:1 by Mikael Pettersson <mikpe@…>, 9 years ago

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.

comment:2 by Kohei Takahashi <flast@…>, 8 years ago

Component: Building Boostbuild
Owner: set to Vladimir Prus

comment:3 by Steven Watanabe, 8 years ago

Resolution: fixed
Status: newclosed

I've fixed this by relaxing the alignment constraint to check for the alignment of LIST * instead of its size.

Note: See TracTickets for help on using tickets.