Linux debuggers
 help / color / mirror / Atom feed
From: "Petr Tesařík" <petr@tesarici.cz>
To: Stephen Brennan <stephen.s.brennan@oracle.com>
Cc: linux-debuggers@vger.kernel.org
Subject: Re: [PATCH v2 1/1] kernel/config: Introduce CONFIG_DEBUG_INFO_IKCONFIG
Date: Thu, 26 Oct 2023 17:02:13 +0200	[thread overview]
Message-ID: <20231026170213.202722da@meshulam.tesarici.cz> (raw)
In-Reply-To: <20231025223640.1132047-2-stephen.s.brennan@oracle.com>

Hi Stephen,

you mentioned yesterday that you couldn't figure out how binutils
determines which sections contain debugging information. I was curious.
As expected, the logic is in libbfd. There is some helpful code and
comment in _bfd_elf_make_section_from_shdr():

  if ((flags & SEC_ALLOC) == 0)
    {
      /* The debugging sections appear to be recognized only by name,
	 not any sort of flag.  Their SEC_ALLOC bits are cleared.  */
      if (name [0] == '.')
	{
	  if (startswith (name, ".debug")
	      || startswith (name, ".gnu.debuglto_.debug_")
	      || startswith (name, ".gnu.linkonce.wi.")
	      || startswith (name, ".zdebug"))
	    flags |= SEC_DEBUGGING | SEC_ELF_OCTETS;
	  else if (startswith (name, GNU_BUILD_ATTRS_SECTION_NAME)
		   || startswith (name, ".note.gnu"))
	    {
	      flags |= SEC_ELF_OCTETS;
	      opb = 1;
	    }
	  else if (startswith (name, ".line")
		   || startswith (name, ".stab")
		   || strcmp (name, ".gdb_index") == 0)
	    flags |= SEC_DEBUGGING;
	}
    }

Your section name starts with .debug, which looks good to me, and
definitely better than any of the alternatives.

Petr T

On Wed, 25 Oct 2023 15:36:40 -0700
Stephen Brennan <stephen.s.brennan@oracle.com> wrote:

> The option CONFIG_IKCONFIG allows the gzip compressed kernel
> configuration to be included into vmlinux or a module. In these cases,
> debuggers can access the config data and use it to adjust their behavior
> according to the configuration. However, distributions rarely enable
> this, likely because it uses a fair bit of kernel memory which cannot be
> swapped out.
> 
> This means that in practice, the kernel configuration is rarely
> available to debuggers.
> 
> So, introduce an alternative, CONFIG_DEBUG_INFO_IKCONFIG. This strategy,
> which is only available if IKCONFIG is not already built-in, adds a
> section ".debug_linux_ikconfig", to the vmlinux ELF. It will be stripped
> out of the final images, but will remain in the debuginfo files. So
> debuggers which rely on vmlinux debuginfo can have access to the kernel
> configuration, without incurring a cost to the kernel at runtime.
> 
> The configuration is enabled whenever DEBUG_INFO=y and IKCONFIG!=y. The
> added section is not large compared to debug info sizes. It won't affect
> the runtime kernel at all, and this default will ensure that
> distributions intending to create useful debuginfo will get this new
> addition for kernel debuggers.
> 
> Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
> ---
>  include/asm-generic/vmlinux.lds.h |  3 ++-
>  kernel/Makefile                   |  1 +
>  kernel/configs-debug.S            | 18 ++++++++++++++++++
>  lib/Kconfig.debug                 | 15 +++++++++++++++
>  4 files changed, 36 insertions(+), 1 deletion(-)
>  create mode 100644 kernel/configs-debug.S
> 
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index 9c59409104f6..025b0bfe17bf 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -824,7 +824,8 @@
>  		.comment 0 : { *(.comment) }				\
>  		.symtab 0 : { *(.symtab) }				\
>  		.strtab 0 : { *(.strtab) }				\
> -		.shstrtab 0 : { *(.shstrtab) }
> +		.shstrtab 0 : { *(.shstrtab) }				\
> +		.debug_linux_ikconfig 0 : { *(.debug_linux_ikconfig) }
>  
>  #ifdef CONFIG_GENERIC_BUG
>  #define BUG_TABLE							\
> diff --git a/kernel/Makefile b/kernel/Makefile
> index 3947122d618b..e2f517a10f04 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -138,6 +138,7 @@ KCSAN_SANITIZE_stackleak.o := n
>  KCOV_INSTRUMENT_stackleak.o := n
>  
>  obj-$(CONFIG_SCF_TORTURE_TEST) += scftorture.o
> +obj-$(CONFIG_DEBUG_INFO_IKCONFIG) += configs-debug.o
>  
>  $(obj)/configs.o: $(obj)/config_data.gz
>  
> diff --git a/kernel/configs-debug.S b/kernel/configs-debug.S
> new file mode 100644
> index 000000000000..d0dd5c2f7bd5
> --- /dev/null
> +++ b/kernel/configs-debug.S
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0-only
> + *
> + * Inline kernel configuration for debuginfo files
> + *
> + * Copyright (c) 2023, Oracle and/or its affiliates.
> + */
> +
> +/*
> + * By using the same "IKCFG_ST" and "IKCFG_ED" markers found in configs.c, we
> + * can ensure that the resulting debuginfo files can be read by
> + * scripts/extract-ikconfig. Unfortunately, this means that the contents of the
> + * section cannot be directly extracted and used. Since debuggers should be able
> + * to trim these markers off trivially, this is a good tradeoff.
> + */
> +	.section .debug_linux_ikconfig
> +	.ascii "IKCFG_ST"
> +	.incbin "kernel/config_data.gz"
> +	.ascii "IKCFG_ED"
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index fa307f93fa2e..c43a874ea584 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -429,6 +429,21 @@ config GDB_SCRIPTS
>  	  instance. See Documentation/dev-tools/gdb-kernel-debugging.rst
>  	  for further details.
>  
> +config DEBUG_INFO_IKCONFIG
> +	bool "Embed KConfig in debuginfo, if not already present"
> +	depends on IKCONFIG!=y
> +	default y if IKCONFIG!=y
> +	help
> +	  This provides the gzip-compressed KConfig information in an ELF
> +	  section called .ikconfig which will be stripped out of the final
> +	  bootable image, but remain in the debuginfo. Debuggers that are aware
> +	  of this can use this to customize their behavior to the kernel
> +	  configuration, without requiring the configuration information to be
> +	  stored in the kernel like CONFIG_IKCONFIG does. This configuration is
> +	  unnecessary when CONFIG_IKCONFIG is enabled, since the data can be
> +	  found in the .rodata section in that case (see
> +	  scripts/extract-ikconfig).
> +
>  endif # DEBUG_INFO
>  
>  config FRAME_WARN


  reply	other threads:[~2023-10-26 15:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-25 22:36 [PATCH v2 0/1] Introduce CONFIG_DEBUG_INFO_IKCONFIG Stephen Brennan
2023-10-25 22:36 ` [PATCH v2 1/1] kernel/config: " Stephen Brennan
2023-10-26 15:02   ` Petr Tesařík [this message]
2023-10-26 22:52   ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231026170213.202722da@meshulam.tesarici.cz \
    --to=petr@tesarici.cz \
    --cc=linux-debuggers@vger.kernel.org \
    --cc=stephen.s.brennan@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox