This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] [MIPS] Raise highest supported EI_ABIVERSION value
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Mihailo Stojanović <mihailo dot stojanovic at rt-rk dot com>
- Cc: <libc-alpha at sourceware dot org>, "Maciej W . Rozycki" <macro at wdc dot com>, Carlos O'Donell <carlos at redhat dot com>, Dragan Mladjenovic <dragan dot mladjenovic at rt-rk dot com>
- Date: Tue, 13 Aug 2019 15:35:06 +0000
- Subject: Re: [PATCH] [MIPS] Raise highest supported EI_ABIVERSION value
- Ironport-sdr: Upef/29hjr14BG1tjfBei3HlBE++u7zhwtuWETb7C1XWYOT5Ac7YlkZKcuW+grGNB5W0do7u11 pUM5tPwecYTwyVUg0be8yMv7HEs/xIeQimjV0++FeFKJJ54cNE62UP9KJSLFOboW89YNnRZLXG NAOOdLPlDSKJsDabFYLqdLPXy+B+I3CxCyraKR9gO6tkFzFxLsxPZTBnNlTHm2PAM7W9fAWGwO 0MlFjbbsdxIDtgQgA7v9JGpUwa3Jap3vI3HljbgDM+GMTEnoB1rH30uHw2OzkjAUtNWFCimJyn Ipk=
- Ironport-sdr: EDz9hiotHP50h0Gq4O9XMhnR6m1XyxmiVN7Mbc+db+uv1xQ4WJAFvCng2ZowtHzyNB5pKipoym TRXaAz06ywBJoP0N1sjCJ85dwYjVV/spomdATzMuAe985eL6nC2Yr8Nkj0zDXqAdEwl6njlAds P8M9qWBbis9bJLy+qVGl5sguJi2eO4JLhtRECX5EHjYSfYi9KgTpOZ23hZ3rLU5OmJG0bKxMKm W/Q9toqyJ//4S6gSpt+p6m9GFDWva4LWA7WtX1H5VERCjyKSdZfExNCM5JZtCic2FUZdudZxI3 BQ0=
- References: <1565360776-31536-1-git-send-email-mihailo.stojanovic@rt-rk.com> <alpine.DEB.2.21.1908091427390.28808@digraph.polyomino.org.uk> <cf24478c-ec1c-838c-58ef-d91dbfb337f4@rt-rk.com>
On Tue, 13 Aug 2019, Mihailo Stojanović wrote:
> Seeing as this is a trivial ABI version increment proposition,
> I believe that including a testcase is superfluous (even more
> so considering that the original issue [1] has a corresponding
> testcase).
A corresponding testcase that did not discover this bug. (I should add:
as a bug that was user-visible in a release, it should also be filed in
Bugzilla; then, once fixed, the bug should be marked RESOLVED / FIXED with
the target milestone set to the first mainline release that will have the
fix, so that it then appears in the automatically-generated list of fixed
bugs in the NEWS file for that release.)
When we discover a bug in some feature / previous bug fix, that was not
shown up by the tests added with that feature / bug fix, that indicates
missing test coverage, and so a new test should typically be added along
with the fix.
> Furthermore, testing this patch requires static linker cooperation,
> which means the undefined hidden and internal weak symbol
> handling in static linker must be checked during glibc configuration.
>
> If you think that the testcase is needed anyway, what I had in
> mind was checking the static linker in the configure script, and
> then enabling/disabling the test based on the result. The test
> would just need to execute without "ABI version invalid" error
> message.
Yes, a test with such configure test support seems appropriate, if the
test would fail when using an older static linker. Please make sure a
comment on the configure test says what binutils release was the first one
with the fix, so that it's obvious at what point we can remove the
configure test as no longer needed.
What exactly would go wrong when using an older static linker? If the
test would fail to link, then a configure test is needed. If the test
would simply wrongly PASS even without the rest of this glibc patch,
because the older linker doesn't set EI_ABIVERSION for this, I don't think
the configure test is needed. I'm guessing this test does not need to
check the values of symbols at runtime because the existing tests deal
with that.
--
Joseph S. Myers
joseph@codesourcery.com