4 messages, 3 authors, 2008-07-07 · open the first message on its own page
From: Roland McGrath <hidden>
Date: 2008-07-04 02:20:17
Why not just use ELF_HWCAP for this? It looks like powerpc only has 3 bits left there (keeping it to 32), but 3 is not 0. If not that, why not use dsocaps? That is, some magic in the vDSO, which glibc already supports on all machines where it uses the vDSO. (For how it works, see the use in arch/x86/vdso/vdso32/note.S for CONFIG_XEN.) Thanks, Roland
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2008-07-07 05:49:53
On Thu, 2008-07-03 at 19:19 -0700, Roland McGrath wrote:
Why not just use ELF_HWCAP for this? It looks like powerpc only has 3 bits left there (keeping it to 32), but 3 is not 0. If not that, why not use dsocaps? That is, some magic in the vDSO, which glibc already supports on all machines where it uses the vDSO. (For how it works, see the use in arch/x86/vdso/vdso32/note.S for CONFIG_XEN.)
Well, we use strings to represent the platforms already (ie, the actual CPU microarchitecture). Fitting those into bits would be annoying, it makes sense to have AT_BASE_PLATFORM to be the "base" variant of AT_PLATFORM. _However_ there is a bug in that this patch adds an entry without bumping the number of entries in the cached array (ie. AT_VECTOR_SIZE_BASE needs to be updated). Ben.
From: Nathan Lynch <hidden>
Date: 2008-07-07 22:17:54
Benjamin Herrenschmidt wrote:
On Thu, 2008-07-03 at 19:19 -0700, Roland McGrath wrote:quoted
Why not just use ELF_HWCAP for this? It looks like powerpc only has 3 bits left there (keeping it to 32), but 3 is not 0. If not that, why not use dsocaps? That is, some magic in the vDSO, which glibc already supports on all machines where it uses the vDSO. (For how it works, see the use in arch/x86/vdso/vdso32/note.S for CONFIG_XEN.)Well, we use strings to represent the platforms already (ie, the actual CPU microarchitecture). Fitting those into bits would be annoying, it makes sense to have AT_BASE_PLATFORM to be the "base" variant of AT_PLATFORM. _However_ there is a bug in that this patch adds an entry without bumping the number of entries in the cached array (ie. AT_VECTOR_SIZE_BASE needs to be updated).
Ugh, yes. I was hoping to work this in such a way that AT_VECTOR_SIZE (and thus the size of mm_struct) increases only for architectures that implement AT_BASE_PLATFORM... would it be wrong to account for it in AT_VECTOR_SIZE_ARCH?
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2008-07-07 23:02:03
On Mon, 2008-07-07 at 17:17 -0500, Nathan Lynch wrote:
Benjamin Herrenschmidt wrote:quoted
On Thu, 2008-07-03 at 19:19 -0700, Roland McGrath wrote:quoted
Why not just use ELF_HWCAP for this? It looks like powerpc only has 3 bits left there (keeping it to 32), but 3 is not 0. If not that, why not use dsocaps? That is, some magic in the vDSO, which glibc already supports on all machines where it uses the vDSO. (For how it works, see the use in arch/x86/vdso/vdso32/note.S for CONFIG_XEN.)Well, we use strings to represent the platforms already (ie, the actual CPU microarchitecture). Fitting those into bits would be annoying, it makes sense to have AT_BASE_PLATFORM to be the "base" variant of AT_PLATFORM. _However_ there is a bug in that this patch adds an entry without bumping the number of entries in the cached array (ie. AT_VECTOR_SIZE_BASE needs to be updated).Ugh, yes. I was hoping to work this in such a way that AT_VECTOR_SIZE (and thus the size of mm_struct) increases only for architectures that implement AT_BASE_PLATFORM... would it be wrong to account for it in AT_VECTOR_SIZE_ARCH?
Yes. The later is for things added from ARCH_DLINFO. Since the code for AT_BASE_PLATFORM is in the generic binfmt_elf, it would be asking for trouble to not account for it in the base AT_VECTOR_SIZE. Ben.