This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add new script

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:
> 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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]