[PATCH] um: fix CONFIG_GCOV for built-in code

[PATCH] um: fix CONFIG_GCOV for built-in code

[Alex Hung]

From: Johannes Berg <johannes@sipsolutions.net>

With contemporary toolchains, CONFIG_GCOV doesn't work because
gcov now relies on both init and exit handlers, but those are
discarded from the binary. Fix the linker scripts to keep them
instead, so that CONFIG_GCOV can work again.

Note that this does not make it work in modules yet, since we
don't call their exit handlers.

Note: the .init_array.* wildcard and the RUNTIME_DISCARD_EXIT
define are already present in this tree; only the matching
.fini_array.* wildcard remained to be added.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Alex Hung <alex.hung@amd.com>
---

This is a revived patch. The original can be found at
https://lkml.iu.edu/hypermail/linux/kernel/2103.1/06608.html

 arch/um/include/asm/common.lds.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/um/include/asm/common.lds.S b/arch/um/include/asm/common.lds.S
index fd481ac371de..2ed213913afe 100644
--- a/arch/um/include/asm/common.lds.S
+++ b/arch/um/include/asm/common.lds.S
@@ -91,6 +91,7 @@
   .fini_array : {
 	__fini_array_start = .;
 	*(.fini_array)
+	*(.fini_array.*)
 	__fini_array_end = .;
   }

--
2.43.0

Re: [PATCH] um: fix CONFIG_GCOV for built-in code

[Alex Hung]

Hi,

Any comments or concerns on this patch? Is it ready to be merged?

On 7/27/26 13:55, Alex Hung wrote:
> From: Johannes Berg <johannes@sipsolutions.net>
> 
> With contemporary toolchains, CONFIG_GCOV doesn't work because
> gcov now relies on both init and exit handlers, but those are
> discarded from the binary. Fix the linker scripts to keep them
> instead, so that CONFIG_GCOV can work again.
> 
> Note that this does not make it work in modules yet, since we
> don't call their exit handlers.
> 
> Note: the .init_array.* wildcard and the RUNTIME_DISCARD_EXIT
> define are already present in this tree; only the matching
> .fini_array.* wildcard remained to be added.
> 
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> Signed-off-by: Alex Hung <alex.hung@amd.com>
> ---
> 
> This is a revived patch. The original can be found at
> https://lkml.iu.edu/hypermail/linux/kernel/2103.1/06608.html
> 
>   arch/um/include/asm/common.lds.S | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/arch/um/include/asm/common.lds.S b/arch/um/include/asm/common.lds.S
> index fd481ac371de..2ed213913afe 100644
> --- a/arch/um/include/asm/common.lds.S
> +++ b/arch/um/include/asm/common.lds.S
> @@ -91,6 +91,7 @@
>     .fini_array : {
>   	__fini_array_start = .;
>   	*(.fini_array)
> +	*(.fini_array.*)
>   	__fini_array_end = .;
>     }
> 
> --
> 2.43.0
> 

Re: [PATCH] um: fix CONFIG_GCOV for built-in code

[Alex Hung]

Ping for comments for this patch. Is it possible to merge for kernel 7.3 
if there are no concerns?

On 8/10/26 07:51, Alex Hung wrote:
> Hi,
> 
> Any comments or concerns on this patch? Is it ready to be merged?
> 
> On 7/27/26 13:55, Alex Hung wrote:
>> From: Johannes Berg <johannes@sipsolutions.net>
>>
>> With contemporary toolchains, CONFIG_GCOV doesn't work because
>> gcov now relies on both init and exit handlers, but those are
>> discarded from the binary. Fix the linker scripts to keep them
>> instead, so that CONFIG_GCOV can work again.
>>
>> Note that this does not make it work in modules yet, since we
>> don't call their exit handlers.
>>
>> Note: the .init_array.* wildcard and the RUNTIME_DISCARD_EXIT
>> define are already present in this tree; only the matching
>> .fini_array.* wildcard remained to be added.
>>
>> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
>> Signed-off-by: Alex Hung <alex.hung@amd.com>
>> ---
>>
>> This is a revived patch. The original can be found at
>> https://lkml.iu.edu/hypermail/linux/kernel/2103.1/06608.html
>>
>>   arch/um/include/asm/common.lds.S | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/um/include/asm/common.lds.S b/arch/um/include/asm/ 
>> common.lds.S
>> index fd481ac371de..2ed213913afe 100644
>> --- a/arch/um/include/asm/common.lds.S
>> +++ b/arch/um/include/asm/common.lds.S
>> @@ -91,6 +91,7 @@
>>     .fini_array : {
>>       __fini_array_start = .;
>>       *(.fini_array)
>> +    *(.fini_array.*)
>>       __fini_array_end = .;
>>     }
>>
>> -- 
>> 2.43.0
>>
> 

Re: [PATCH] um: fix CONFIG_GCOV for built-in code

[Mariia Nikitash]

Hi Alex,

I tested this while investigating GCC/GCOV coverage under UML using KUnit.

Tested on:
  Architecture: x86_64 UML
  Kernel: v7.3-rc3-61-gbc77531b2a6f
  KUnit configs: default.config + coverage_uml.config
  Compilers: GCC 13.3.0 and GCC 16.2.0

With GCC 13.3, the unpatched tree produced 731 .gcno files and
0 .gcda files after the KUnit run. With the patch applied, the
same run produced 731 .gcno files and 704 .gcda files, and LCOV
was able to generate coverage successfully.

I also reproduced the same result with GCC 16.2:

  without patch: 731 .gcno / 0 .gcda
  with patch:    731 .gcno / 704 .gcda

LCOV coverage generation also completed successfully with GCC 16.2.

Tested-by: Mariia Nikitash <nikitash.mariiaw@gmail.com>

Thanks,
Mariia

Re: [PATCH] um: fix CONFIG_GCOV for built-in code

[Kees Cook]

On Mon, 27 Jul 2026 13:55:15 -0600, Alex Hung wrote:
> With contemporary toolchains, CONFIG_GCOV doesn't work because
> gcov now relies on both init and exit handlers, but those are
> discarded from the binary. Fix the linker scripts to keep them
> instead, so that CONFIG_GCOV can work again.
> 
> Note that this does not make it work in modules yet, since we
> don't call their exit handlers.
> 
> [...]

Applied to for-next/hardening, thanks! Only a 5 year delay. :P
What else is needed from the original series to get the full coverage?
https://lore.kernel.org/all/20210312095526.197739-1-johannes@sipsolutions.net/

[1/1] um: fix CONFIG_GCOV for built-in code
      https://git.kernel.org/kees/c/760f96b7f54b

Take care,

-Kees

-- 
Kees Cook

Re: [PATCH] um: fix CONFIG_GCOV for built-in code

[Johannes Berg]

On Wed, 2026-09-23 at 20:42 -0700, Kees Cook wrote:
> 
> What else is needed from the original series to get the full coverage?
> https://lore.kernel.org/all/20210312095526.197739-1-johannes@sipsolutions.net/

Back then I gave up and wasn't convinced it's actually doable in
general:
https://lore.kernel.org/all/d36ea54d8c0a8dd706826ba844a6f27691f45d55.camel@sipsolutions.net/

johannes