svn commit: r357695 - in head: sys/kern sys/sys usr.bin/procstat

[John Baldwin]

On 2/10/20 11:15 AM, Konstantin Belousov wrote:
> On Mon, Feb 10, 2020 at 10:11:43AM -0800, John Baldwin wrote:
>> On 2/9/20 4:10 AM, Konstantin Belousov wrote:
>>> Author: kib
>>> Date: Sun Feb  9 12:10:37 2020
>>> New Revision: 357695
>>> URL: https://svnweb.freebsd.org/changeset/base/357695
>>>
>>> Log:
>>>   Add AT_BSDFLAGS auxv entry.
>>>   
>>>   The intent is to provide bsd-specific flags relevant to interpreter
>>>   and C runtime.  I did not want to reuse AT_FLAGS which is common ELF
>>>   auxv entry.
>>>   
>>>   Use bsdflags to report kernel support for sigfastblock(2).  This
>>>   allows rtld and libthr to safely infer the syscall presence without
>>>   SIGSYS.  The tunable kern.elf{32,64}.sigfastblock blocks reporting.
>>>   
>>>   Tested by:	pho
>>>   Disscussed with:	cem, emaste, jilles
>>>   Sponsored by:	The FreeBSD Foundation
>>>   Differential revision:	https://reviews.freebsd.org/D12773
>>
>> I find adding a new auxv type curious.  The MIPS ABI doc says that
>> "bits under the 0xff000000 mask are reserved for system semantics".
>> The powerpc and x86-64 docs don't define any bits at all.  In
>> practice I think we are free to use AT_FLAGS however we wish as no
>> use cases of "standard" bits have arisen since AT_FLAGS was first
>> defined.
> 
> So you would prefer to have me used AT_FLAGS for sigfastblock indicator ?
> I am feeling uncomfortable doing that.
> 
> My reasoning, to reformulate it from what I wrote in the commit message,
> is to not pollute neither compilation nor ABI namespace for bsd-specific
> flags.  AT_FLAGS was not touched by anybody and I do not want to open
> it for use, since ABI group my finally find some use for it.

I would bet money the ABI group will never use AT_FLAGS since they haven't
found a use yet.  That said, adding a new auxv vector isn't the end of the
world.  I'll work on a patch to GDB when I get some spare time.

-- 
John Baldwin