On Wed, May 26, 2010 at 02:59, Geert Uytterhoeven wrote:
quoted text
> 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.

quoted text
> 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
--
unsubscribe notice
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/