Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1107201pxf; Fri, 12 Mar 2021 01:59:04 -0800 (PST) X-Google-Smtp-Source: ABdhPJyShssqF/qbQ/oCMIZYkWtoQMH9VD5Juf7ZgyCinNzoIN0ffkrC2WnLt4RTZi6E5Ay/1Cr2 X-Received: by 2002:a17:906:32d1:: with SMTP id k17mr7592360ejk.94.1615543144081; Fri, 12 Mar 2021 01:59:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615543144; cv=none; d=google.com; s=arc-20160816; b=ivprt9PxiCcS6dhI8lCo+tc+Ugwva+SPzKCY/sjwKw+MlJwjfEGtEk0jdEFYZWFphy dF/Gtjozf3BcxzN2weXV1e1Cm/StQX/QVIxAaOVwfjfjsqUAqhHQ1I7aRUzzBunZ/yG3 MykJi9yYTFwTYURVaN0Vf653O5ac2VBOJqAKXkSjo/h1BuAzPVBuyio1gA7iSgcAp5SM 0/MEkwYlXTcOKVlJ/JqPwjtq8tpnTeWjkd41KBJo+TR+ZIppRII2QmYQwpaMFSTCLUoh x5fb7THmZMFCIRyeFLtD7Hg4S/+J/xL31RLuKC23P6p2fM1eVd/DlbLpA/Vp/nF6f471 UgRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=trhF+gBGuvK7U4SWF2uLsBLC72Tm3Y0+zAawpTVLmsE=; b=mqIPJMRMLJBVSvzo/uY025+M4VVmLdrxCNctZL66QHGefL3/DLXHRYedj5yyBy+PEf xQshovvhuUggmqspHp6CezG8Ar/3rQye9YWogvvUQaGHmMYfyOUf6xL1fZMy2Sk+dnEK RaKdnvjs3tHUi38lw54RgNaq6/FPf/uZKdhLQfT3GAGIHIDDGQBfjadQRT6I5pPFuGPe dukIot1I3TV8oCPyf5Uz2XqJ3EikeeR0k7ajJF7c+uQgIVjuFg1A3ge/dE3NP59bz7aK 5XZTS0VC00hzv8FtWH0kPfgyTmnnaHeCHxKXMzCstEkfR28Ukc7tzISRRz1kSC8xEBRF CfRg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u21si3615096ejt.396.2021.03.12.01.58.41; Fri, 12 Mar 2021 01:59:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233187AbhCLJ4E (ORCPT + 99 others); Fri, 12 Mar 2021 04:56:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56172 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232862AbhCLJzp (ORCPT ); Fri, 12 Mar 2021 04:55:45 -0500 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 78003C061574; Fri, 12 Mar 2021 01:55:45 -0800 (PST) Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94) (envelope-from ) id 1lKeW0-00F7m8-Gm; Fri, 12 Mar 2021 10:55:28 +0100 From: Johannes Berg To: linux-kernel@vger.kernel.org, linux-um@lists.infradead.org Cc: Jessica Yu , Alexander Viro , linux-fsdevel@vger.kernel.org Subject: [PATCH 0/6] um: fix up CONFIG_GCOV support Date: Fri, 12 Mar 2021 10:55:20 +0100 Message-Id: <20210312095526.197739-1-johannes@sipsolutions.net> X-Mailer: git-send-email 2.29.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org CONFIG_GCOV is fairly useful for ARCH=um (e.g. with kunit, though my main use case is a bit different) since it writes coverage data directly out like a normal userspace binary. Theoretically, that is. Unfortunately, it's broken in multiple ways today: 1) it doesn't like, due to 'mangle_path' in seq_file, and the only solution to that seems to be to rename our symbol, but that's not so bad, and "mangle_path" sounds very generic anyway, which it isn't quite 2) gcov requires exit handlers to write out the data, and those are never called for modules, config CONSTRUCTORS exists for init handlers, so add CONFIG_MODULE_DESTRUCTORS here that we can then select in ARCH=um 3) As mentioned above, gcov requires init/exit handlers, but they aren't linked into binary properly, that's easy to fix. 4) gcda files are then written, so .gitignore them 5) it's not always useful to create coverage data for the *entire* kernel, so I've split off CONFIG_GCOV_BASE from CONFIG_GCOV to allow option in only in some places, which of course requires adding the necessary "subdir-cflags" or "CFLAGS_obj" changes in the places where it's desired, as local patches. None of these changes (hopefully) seem too controversional, biggest are the module changes but obviously they compile to nothing if the architecture doesn't WANT_MODULE_DESTRUCTORS. Any thoughts on how to merge this? The seq_file/.gitignore changes are independent at least code-wise, though of course it only works with the seq_file changes (.gitignore doesn't matter, of course), while the module changes are a requirement for the later ARCH=um patches since the Kconfig symbol has to exist. Perhaps I can just get ACKs on all the patches and then they can go through the UML tree? Thanks, johannes