From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 70464385E003; Wed, 25 Mar 2020 21:04:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 70464385E003 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id EFC0D1E5F8; Wed, 25 Mar 2020 17:04:36 -0400 (EDT) Subject: Re: [PATCH] Support AT_BSDFLAGS on FreeBSD. To: John Baldwin , gdb-patches@sourceware.org, binutils@sourceware.org References: <20200325172548.5726-1-jhb@FreeBSD.org> From: Simon Marchi Message-ID: Date: Wed, 25 Mar 2020 17:04:36 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-14.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 21:04:38 -0000 On 2020-03-25 4:37 p.m., John Baldwin wrote: > I can add something. To date there aren't any user-visible changes. There is > one flag defined that indicates that the running FreeBSD kernel supports a new > 'sigfastblock' system call that allows a thread to register a signal mask in user > memory that is treated as the signal mask so that sigprocmask() can just modify > that mask in userland without invoking actual system calls. It's not documented > though aside from the upstream commit message. The commit changes fbsd_print_auxv_entry, so I presume that GDB will start printing this auxv entry, if it is present, won't it? Isn't that a user-visible change? Even if there is no user-visible change, it's good to mention it, as well as why you'd like to make the change. The reviewer and future reader of this commit are not in your head and don't have the same context to know why this was added. Simon