This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add new script add-abilist.py
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Roland McGrath <roland at hack dot frob dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 05 Mar 2015 16:41:10 -0500
- Subject: Re: [PATCH] Add new script add-abilist.py
- Authentication-results: sourceware.org; auth=none
- References: <20150302080300 dot B464D4242A0BE at oldenburg dot str dot redhat dot com> <20150302201942 dot AC9532C39F1 at topped-with-meat dot com> <54F4CCCC dot 3070500 at redhat dot com> <20150302205928 dot C13FE2C3A08 at topped-with-meat dot com> <54F4CFCE dot 1020700 at redhat dot com> <54F8AED7 dot 2090109 at redhat dot com> <54F8C425 dot 8070501 at redhat dot com>
On 03/05/2015 04:01 PM, Florian Weimer wrote:
> On 03/05/2015 08:30 PM, Carlos O'Donell wrote:
>> On 03/02/2015 04:02 PM, Florian Weimer wrote:
>>> On 03/02/2015 09:59 PM, Roland McGrath wrote:
>>>>> It's very difficult to find. :-) I haven't tried it, but I think it
>>>>> only patches the current abilist file, and not the other architectures.
>>>>
>>>> That's true. It does an empirical update to the actual new reality, rather
>>>> than a specified updated to a putative new reality.
>>>
>>> I think both approaches have their advantages, at least for function
>>> symbols. Data symbols with their size information are more tricky.
>>
>> The `make update-abi` method that Roland describes is part of the general
>> glibc `Release` documentation here and referenced from the `Release`
>> process followed by a release manager or machine maintainer during each
>> release:
>>
>> https://sourceware.org/glibc/wiki/Regeneration
>
> I was under the impression it is the job of the patch submitter to
> ensure that a patch does not cause *known* test suite failures on any
> architecture. To me, this clearly means that I have to update the
> *.abilist files in any patch that updates the ABI.
You do.
> Doing it at release time might work as well, but it seems much better to
> me to avoid any known test suite failures during development, so that
> interpreting test suite results is easy as possible.
It is.
If your script helps with that, by say skipping the manual process of
running `make update-abi` on one system, and propagating that identical
change to all other target abi list files, then that's a good thing.
What you have proposed appears to be a "first step", in that it allows
you to add entries to all ABI files one symbol at a time.
Could we have a `make all-update-abi` target that ran `make update-abi`
and then ran your script to propagate all the changes to all other
targets? That's the only useful case I can come up with where your
script helps.
Thoughts?
Cheers,
Carlos.