This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Don't check ABI for _nl_default_dirname
On Sat, Dec 08, 2012 at 09:57:13PM +0100, Andi Kleen wrote:
> > Does that make sense?
>
> Not for _nl_default_dirname at least. The whole concept of an API
> that depends on the prefix is obviously broken.
Not really. The prefix is constant for a distribution; any change in
it is essentially an ABI change for the distribution, which glibc
should be under no obligation to verify. The attempt here is to
verify that no *code change* results in broken ABI.
> As far as I can tell noone should rely on that array size anyways,
> it's simply a bug in the ABI checker that it checks it. I provided a
> reasonable solution and you want a overengineered pony instead.
The simplest example I can think of for this would be code generated
(or written by hand) to optimize copying from such a variable using
extensions such as AVX/SSE. The size will be considered at compile
time and a later array size change will break such code. So I
wouldn't call this check over-engineered.
> The test suite already needs various undocumented magic incarnations
> to work (copy libstdc++ and libgcc). If I had to provide manual
> overrides for symbols like this it would be even worse and I have
> no idea how some newbie developer would ever learn to do that.
> (and no the fix is not to write more docs, the fix is to make check
> reliable by itself)
I had started working on this (the libstdc++/libgcc problem) some
months ago and also committed a couple of patches to make this work
seamlessly (see the new --inhibit-cache argument in ld.so - it is
useful in general, but was specifically included to isolate the test
environment), but dropped it in favour of some more interesting
problems. I'll pick this back up after 2.17 goes out.
As for my suggestion in the earlier email, I'll clarify since my idea
was a little different fomr what Carlos suggested. When I said
'adjust expectations', I meant providing the ability to adjust the
expected size of a data symbol based on the configurable macro it
depends on. For example, for _nl_default_dirname, we could have the
entry as:
_nl_default_dirname V 0 LOCALEDIR
where column 4 is a C macro and column 3 is the size in addition to
the macro value size.
Siddhesh