[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061110144922.GA8155@in.ibm.com>
Date: Fri, 10 Nov 2006 09:49:22 -0500
From: Vivek Goyal <vgoyal@...ibm.com>
To: Magnus Damm <magnus.damm@...il.com>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
Magnus Damm <magnus@...inux.co.jp>,
linux-kernel@...r.kernel.org, Vivek Goyal <vgoyal@...ibm.com>,
Andi Kleen <ak@....de>, fastboot@...ts.osdl.org,
Horms <horms@...ge.net.au>, Dave Anderson <anderson@...hat.com>
Subject: Re: [PATCH 02/02] Elf: Align elf notes properly
On Fri, Nov 10, 2006 at 03:53:57PM +0900, Magnus Damm wrote:
[..]
> >Sure.
> >
> >To verify your claim that 8 byte alignment is correct I checked the
> >core dump code in fs/binfmt_elf.c in the linux kernel. That always
> >uses 4 byte alignment. Therefore it appears clear that only doing
> >4 byte alignment is not a local misreading of the spec, and is used in
> >other implementations. If you can find an implementation that uses
> >8 byte alignment I am willing to consider it.
>
> Yes, fs/binfmt_elf.c is one of the files that my patch modifies. There
> are several elf note implementations in the kernel, all seem to use
> 4-byte aligment.
>
> Implementations that use 8-byte alignment:
>
> binutils-2.16.1/bfd/elf.c: elf_core_write_note() is using
> log_file_align which is set to 3 on some 64-bit platforms. 8-byte
> alignment in some cases.
>
> binutils-2.16.1/binutils/readelf.c: process_corefile_note_segment() is
> always using 4-byte alignment though.
>
> >The current situation is that the linux kernel generated application
> >core dumps use 4 byte alignment so I expect that is what existing
> >applications such as gdb expect.
>
> Most applications probably expect 4-byte aligned data. OTOH, I just
> came across HP's ELF-64 Object File Format document. It says that
> 8-byte alignment should be used:
>
> http://devresource.hp.com/drc/STK/docs/refs/elf-64-hp.pdf
>
> So now we have two documents that say 8-byte alignment should be used.
>
> >Therefore we use 4 byte alignment unless it can be shown that the
> >linux core dumps are a fluke and should be fixed.
>
> Ok. Vivek, Dave, anyone? Comments?
>
IMHO, I think we should go by the specs (8byte boundary alignment on 64bit
platforms) until and unless it can be proven that specs are wrong. This
probably will mean that we will break things for sometime (until and unless
it is fixed in tool chain and probably will also break the capability to use
an older kernel for capturing dump). But that's unavoidable if we want to be
compliant to specs.
Thanks
Vivek
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists