Messages in this thread | | | From | Mike Frysinger <> | Date | Wed, 26 May 2010 03:23:02 -0400 | Subject | Re: [PATCH] FLAT: allow arches to declare a larger alignment than the slab |
| |
On Wed, May 26, 2010 at 02:59, Geert Uytterhoeven wrote: > On Wed, May 26, 2010 at 04:23, Jie Zhang wrote: >> On 05/26/2010 07:17 AM, Mike Frysinger wrote: >>> >>> i do not believe that is the reason for this, but unfortunately Jie is >>> about the only one atm who knows the inner details as for why shared >>> FLAT libraries requires 0x20 rather than just 0x4 alignment. i do >>> know that there are some gcc fortran tests that fail otherwise. >>> hopefully he can remember details ;). >>> >> I encountered this issue when investigating some GCC test failures when >> using FLAT. I don't remember if they were in GCC Fortran testsuite. Some >> variables in those test cases were required to be aligned at a large >> boundary, for example 16-byte. I found 0x20 was a reasonably large alignment >> to fix all such failures in GCC testsuite. > > I'm no FLAT expert (except for the AmigaOS HUNK loader :-), but isn't > the core of the > issue that alignment requirements in the object file are no longer > fulfilled after loading, > as a FLAT segment in memory is just allocated using kmalloc(), which may now > return 4-byte aligned blocks?
there are two issues. first, the ARCH_SLAB_MINALIGN define is used to align dynamically packed data on the stack. the alignment of kmalloc has no bearing here because things like the env get packed in and then the ARCH_SLAB_MINALIGN value is manually used to re-align the stack.
second, the define is further used to manually set up alignment of the data section after it has been mmapped in anonymously and made room for shared library data. this too has no kmalloc bearing because mmap sucks things in by grabbing pages manually.
> From looking at <linux/flat.h>, it looks like the FLAT binary format > doesn't contain any > alignment information? So if I put __attribute__((aligned(4096))) in a > file, there's still > no guarantee it will actually be in memory at a 4Ki-aligned address?
i believe that is correct. FLAT behavior today provides alignment of either sizeof(unsigned long) or ARCH_SLAB_MINALIGN.
i imagine something like this would work today because everyone defines it to a constant: -#ifdef ARCH_SLAB_MINALIGN +#if defined(ARCH_SLAB_MINALIGN) && ARCH_SLAB_MINALIGN != 0 but this would break if someone tried using gcc sizeof/alignof/etc... -mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |