lkml.org 
[lkml]   [2006]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 02/02] Elf: Align elf notes properly
    On 11/10/06, Horms <horms@verge.net.au> wrote:
    > On Thu, Nov 09, 2006 at 07:00:22AM -0700, Eric W. Biederman wrote:
    > > Magnus Damm <magnus@valinux.co.jp> writes:
    > >
    > > > elf: Align elf notes properly
    > > >
    > > > The kernel currently contains several elf note aligment implementations. Most
    > > > implementations follow the spec on 32-bit platforms, but none current aligns
    > > > the notes correctly on 64-bit platforms. This patch tries to fix this by
    > > > interpreting the 64-bit and 32-bit elf specs as the following:
    > > >
    > > > offset bytes name
    > > > 0 4 n_namesz -+ -+
    > > > 4 4 n_descsz | elf note header |
    > > > 8 4 n_type -+ | elf note entry size - N4
    > > > 12 N1 name |
    > > > N2 N3 desc -+
    > > >
    > > > WS = word size in bytes (4 for 32 bit, 8 for 64 bit)
    > > > N1 = roundup(n_namesz + sizeof(elf note header), WS) - sizeof(elf note header)
    > > > N2 = sizeof(elf note header) + N1
    > > > N3 = roundup(n_descsz, WS)
    > > > N4 = sizeof(elf note header) + N1 + N2
    > > >
    > > > The elf note header contains three 32-bit values on 32-bit and 64-bit systems.
    > > > The header is followed by name and desc data together with padding. The
    > > > alignment and padding varies depending on the word size.
    > >
    > > I see your point and I disagree. The notes in a kernel generated
    > > core dump do not vary in size. Find me some implementation evidence that
    > > anyone ever added the extra 4 bytes of alignment to the description and the
    > > padding fields and I will be ready to consider this. Currently this
    > > just appears to be reading a draft spec that doesn't match reality.
    >
    > Or perhaps a spec that hasn't been implemented correctly.
    > I guess that the real question is, what padding is correct?

    I see no point in aligning to 32-bit boundaries on 64-bit platforms.
    Their intention was most likely to align to the word size IMO, so this
    is most likely a "thinko" left over from whoever ported the code from
    32-bit to 64-bit.

    How we chose to align on 64-bit platforms is another issue, either we
    fix it soon or live with the fact that we are not following the 64-bit
    draft spec. Either way is fine with me.

    / magnus
    -
    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/

    \
     
     \ /
      Last update: 2006-11-10 05:03    [W:0.030 / U:29.948 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site