[Mesa-dev] [PATCH 2/2] util/ralloc: Make sizeof(linear_header) a multiple of 8

Matt Turner mattst88 at gmail.com
Tue Nov 13 17:44:29 UTC 2018


On Tue, Nov 13, 2018 at 9:43 AM Emil Velikov <emil.l.velikov at gmail.com> wrote:
>
> Hi Matt,
>
> On Mon, 12 Nov 2018 at 21:26, Matt Turner <mattst88 at gmail.com> wrote:
> >
> > Prior to this patch sizeof(linear_header) was 20 bytes in a
> > non-debug build on 32-bit platforms. We do some pointer arithmetic to
> > calculate the next available location with
> >
> >    ptr = (linear_size_chunk *)((char *)&latest[1] + latest->offset);
> >
> > in linear_alloc_child(). The &latest[1] adds 20 bytes, so an allocation
> > would only be 4-byte aligned.
> >
> > On 32-bit SPARC a 'sttw' instruction (which stores a consecutive pair of
> > 4-byte registers to memory) requires an 8-byte aligned address. Such an
> > instruction is used to store to an 8-byte integer type, like intmax_t
> > which is used in glcpp's expression_value_t struct.
> >
> > As a result of the 4-byte alignment returned by linear_alloc_child() we
> > would generate a SIGBUS (unaligned exception) on SPARC.
> >
> > According to the GNU libc manual malloc() always returns memory that has
> > at least an alignment of 8-bytes [1]. I think our allocator should do
> > the same.
> >
> > So, simple fix with two parts:
> >
> >    (1) Increase SUBALLOC_ALIGNMENT to 8 unconditionally.
> >    (2) Mark linear_header with an aligned attribute, which will cause
> >        its sizeof to be rounded up to that alignment. (We already do
> >        this for ralloc_header)
> >
> > With this done, all Mesa's unit tests now pass on SPARC.
> >
> > [1] https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html
> >
> > Fixes: 47e17586924f ("glcpp: use the linear allocator for most objects")
> > Bug: https://bugs.gentoo.org/636326
>
> This patch didn't apply cleanly on 18.3, so I've resolved the trivial conflict.
>
> Fixed patch is at
>
> [1] https://cgit.freedesktop.org/mesa/mesa/commit/?h=staging/18.3&id=44dfbdf989956095e1610ce152e838fd9eeb089f

Perfect, thanks Emil!


More information about the mesa-dev mailing list