[PATCH/RFC 2/2] Cache AT_PLATFORM and AT_L1D_CACHESHAPE from auxvec

Kevin Cernekee cernekee at gmail.com
Sun Apr 17 16:57:40 UTC 2011


On Sun, Apr 17, 2011 at 1:56 AM, Carmelo Amoroso <carmelo73 at gmail.com> wrote:
> I'm really interested into such a thing. I've posted months ago a patch for SH4 to retrieve Cache info through auxvect
> as well (also pagesize).

I do remember seeing your patch on the list.  Didn't realize it was
never merged.

> I think we should do this in a dl_aux_init as in my patch instead of polluting
> all these stuff in __uClibc_main.

I agree conceptually with reading all auxvect variables in a dedicated
function instead of putting an ever-growing list in __uClibc_main().
And I did originally consider _dl_aux_init(), until I saw that
dl-support.c is only used for static builds of libc.  Maybe there is
another place to put the code?

One thing to consider is how much of this code can (and should) be
shared between ld.so and libc.  There were a couple of different
places where the auxvect information was getting grabbed/parsed and
maybe it does make sense to consolidate it somehow.

In the case of memcpy(), one would want to be able to retrieve the
auxvect values on both shared and static versions of libc.  This might
wind up looking a little different from what needs to be done to
extract your SHMLBA value for dynamic linking purposes.

Regarding this part of your patch:

+/* Starting with version 2.6.25-rc1, dcache shape info are passed in auxvect */
+#if __LINUX_KERNEL_VERSION >= KERNEL_VERSION(2,6,25) && defined __sh__
+#define __ASSUME_DCACHESHAPE_AUXVECT	1
+#endif

Is that something that could be figured out at runtime instead, based
on whether there is an auxvect entry with the AT_L1D_CACHESHAPE tag?

I ask, because my architecture doesn't have AT_L1D_CACHESHAPE
implemented in mainline yet...


More information about the uClibc mailing list