Prev: sata_nv times out for BD-ROM iHOS104-08
Next: powernow-k8: section mismatch
From: Mike Frysinger on 26 May 2010 03:50
On Tue, May 25, 2010 at 22: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.

ok, i found the reports Jie worked on originally. the 0x20 value isnt
a hardware restriction or anything. some gcc tests use the alignment
directive and then double check that it was respected. the way the
FLAT loader crams things into the start of the data page before
appending the data breaks this. so 0x20 was selected because, as Jie
said, it seemed to satisfy all of the gcc tests.

presumably this issue could be resolved by changing the FLAT loader to
append this internal state data instead of prepending. that would fix
FLAT behavior wrt alignment directives (up to a page).
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mike Frysinger on 26 May 2010 04:10
On Wed, May 26, 2010 at 03:48, Paul Mundt wrote:
> On Tue, May 25, 2010 at 07:17:16PM -0400, Mike Frysinger wrote:
>> to be sure, we dont need 0x20 alignment in general.  i just figured
>> kill two birds with one patch here.  and Blackfin is already setting
>> ARCH_KMALLOC_MINALIGN to cacheline size, but that wouldnt make any
>> difference in these issues.
>
> I have no objections to adding a new alignment value for binfmt_flat, but
> given the confusion that exists around things like ARCH_SLAB_MINALIGN and
> ARCH_KMALLOC_MINALIGN already today it should be quite obvious what
> exactly the new value is for and what case it is specifically addressing.
> My guess is that the issues you are seeing with the gcc testsuite will
> also pop up on other nommu platforms, so it may be something we want to
> just deal with generically. At least I suspect you guys are running the
> gcc testsuite a lot more frequently than the rest of us!

looking at the linker scripts elf2flt uses, i'm wondering if perhaps
we shouldnt use 0x20 for the FLAT data chunk all the time. it uses
ALIGN(0x20) when packing in the rodata/data/etc... sections, and
obviously this would only work if the starting alignment were 0x20+ to
begin with.

elf2flt.ld.in:
....
. = ALIGN(0x20) ;
*(.rodata)
*(.rodata1)
*(.rodata.*)
*(.gnu.linkonce.r*)
*(.data)
*(.data1)
*(.data.*)
*(.gnu.linkonce.d*)
....

that would address our gcc test issues, but not the current initial
loading crash
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2
Prev: sata_nv times out for BD-ROM iHOS104-08
Next: powernow-k8: section mismatch