After commit da5fb18225b4 ("bpf: Support pre-2.25-binutils objcopy for
vmlinux BTF"), having CONFIG_DEBUG_INFO_BTF enabled but lacking a valid
copy of pahole results in a kernel that will fully compile but fail to
link. The user then has to either install pahole or disable
CONFIG_DEBUG_INFO_BTF and rebuild the kernel but only after their build
has failed, which could have been a significant amount of time depending
on the hardware.
Avoid a poor user experience and require pahole to be installed with an
appropriate version to select and use CONFIG_DEBUG_INFO_BTF, which is
standard for options that require a specific tools version.
Suggested-by: Sedat Dilek <redacted>
Signed-off-by: Nathan Chancellor <redacted>
---
MAINTAINERS | 1 +
init/Kconfig | 4 ++++
lib/Kconfig.debug | 6 ++----
scripts/link-vmlinux.sh | 13 -------------
scripts/pahole-version.sh | 16 ++++++++++++++++
5 files changed, 23 insertions(+), 17 deletions(-)
create mode 100755 scripts/pahole-version.sh
@@ -139,19 +139,6 @@ vmlinux_link()# ${2} - file to dump raw BTF data into gen_btf(){-localpahole_ver--if![-x"$(command-v${PAHOLE})"];then-echo>&2"BTF: ${1}: pahole (${PAHOLE}) is not available"-return1-fi--pahole_ver=$(${PAHOLE}--version|sed-E's/v([0-9]+)\.([0-9]+)/\1\2/')-if["${pahole_ver}"-lt"116"];then-echo>&2"BTF: ${1}: pahole version $(${PAHOLE}--version) is too old, need at least v1.16"-return1-fi-vmlinux_link${1}info"BTF"${2}
@@ -0,0 +1,16 @@+#!/bin/sh+# SPDX-License-Identifier: GPL-2.0+#+# Usage: $ ./scripts/pahole-version.sh pahole+#+# Print the pahole version as a three digit string+# such as `119' for pahole v1.19 etc.++pahole="$*"++if![-x"$(command-v$pahole)"];then+echo0+exit1+fi++$pahole--version|sed-E's/v([0-9]+)\.([0-9]+)/\1\2/'
On Tue, Jan 12, 2021 at 3:06 AM Nathan Chancellor
[off-list ref] wrote:
After commit da5fb18225b4 ("bpf: Support pre-2.25-binutils objcopy for
vmlinux BTF"), having CONFIG_DEBUG_INFO_BTF enabled but lacking a valid
copy of pahole results in a kernel that will fully compile but fail to
link. The user then has to either install pahole or disable
CONFIG_DEBUG_INFO_BTF and rebuild the kernel but only after their build
has failed, which could have been a significant amount of time depending
on the hardware.
Avoid a poor user experience and require pahole to be installed with an
appropriate version to select and use CONFIG_DEBUG_INFO_BTF, which is
standard for options that require a specific tools version.
Suggested-by: Sedat Dilek <redacted>
Signed-off-by: Nathan Chancellor <redacted>
I am not sure if this is the right direction.
I used to believe moving any tool test to the Kconfig
was the right thing to do.
For example, I tried to move the libelf test to Kconfig,
and make STACK_VALIDATION depend on it.
https://patchwork.kernel.org/project/linux-kbuild/patch/1531186516-15764-1-git-send-email-yamada.masahiro@socionext.com/
It was rejected.
In my understanding, it is good to test target toolchains
in Kconfig (e.g. cc-option, ld-option, etc).
As for host tools, in contrast, it is better to _intentionally_
break the build in order to let users know that something needed is missing.
Then, they will install necessary tools or libraries.
It is just a one-time setup, in most cases,
just running 'apt install' or 'dnf install'.
Recently, a similar thing happened to GCC_PLUGINS
https://patchwork.kernel.org/project/linux-kbuild/patch/20201203125700.161354-1-masahiroy@kernel.org/#23855673
Following this pattern, if a new pahole is not installed,
it might be better to break the build instead of hiding
the CONFIG option.
In my case, it is just a matter of 'apt install pahole'.
On some distributions, the bundled pahole is not new enough,
and people may end up with building pahole from the source code.
@@ -139,19 +139,6 @@ vmlinux_link()# ${2} - file to dump raw BTF data into gen_btf(){-localpahole_ver--if![-x"$(command-v${PAHOLE})"];then-echo>&2"BTF: ${1}: pahole (${PAHOLE}) is not available"-return1-fi--pahole_ver=$(${PAHOLE}--version|sed-E's/v([0-9]+)\.([0-9]+)/\1\2/')-if["${pahole_ver}"-lt"116"];then-echo>&2"BTF: ${1}: pahole version $(${PAHOLE}--version) is too old, need at least v1.16"-return1-fi-vmlinux_link${1}info"BTF"${2}
@@ -0,0 +1,16 @@+#!/bin/sh+# SPDX-License-Identifier: GPL-2.0+#+# Usage: $ ./scripts/pahole-version.sh pahole+#+# Print the pahole version as a three digit string+# such as `119' for pahole v1.19 etc.++pahole="$*"++if![-x"$(command-v$pahole)"];then+echo0+exit1+fi++$pahole--version|sed-E's/v([0-9]+)\.([0-9]+)/\1\2/'
On Tue, Jan 12, 2021 at 04:19:01AM +0900, Masahiro Yamada wrote:
On Tue, Jan 12, 2021 at 3:06 AM Nathan Chancellor
[off-list ref] wrote:
quoted
After commit da5fb18225b4 ("bpf: Support pre-2.25-binutils objcopy for
vmlinux BTF"), having CONFIG_DEBUG_INFO_BTF enabled but lacking a valid
copy of pahole results in a kernel that will fully compile but fail to
link. The user then has to either install pahole or disable
CONFIG_DEBUG_INFO_BTF and rebuild the kernel but only after their build
has failed, which could have been a significant amount of time depending
on the hardware.
Avoid a poor user experience and require pahole to be installed with an
appropriate version to select and use CONFIG_DEBUG_INFO_BTF, which is
standard for options that require a specific tools version.
Suggested-by: Sedat Dilek <redacted>
Signed-off-by: Nathan Chancellor <redacted>
I am not sure if this is the right direction.
I used to believe moving any tool test to the Kconfig
was the right thing to do.
For example, I tried to move the libelf test to Kconfig,
and make STACK_VALIDATION depend on it.
https://patchwork.kernel.org/project/linux-kbuild/patch/1531186516-15764-1-git-send-email-yamada.masahiro@socionext.com/
It was rejected.
In my understanding, it is good to test target toolchains
in Kconfig (e.g. cc-option, ld-option, etc).
As for host tools, in contrast, it is better to _intentionally_
break the build in order to let users know that something needed is missing.
Then, they will install necessary tools or libraries.
It is just a one-time setup, in most cases,
just running 'apt install' or 'dnf install'.
Recently, a similar thing happened to GCC_PLUGINS
https://patchwork.kernel.org/project/linux-kbuild/patch/20201203125700.161354-1-masahiroy@kernel.org/#23855673
Following this pattern, if a new pahole is not installed,
it might be better to break the build instead of hiding
the CONFIG option.
In my case, it is just a matter of 'apt install pahole'.
On some distributions, the bundled pahole is not new enough,
and people may end up with building pahole from the source code.
This is fair enough. However, I think that parts of this patch could
still be salvaged into something that fits this by making it so that if
pahole is not installed (CONFIG_PAHOLE_VERSION=0) or too old, the build
errors at the beginning, rather at the end. I am not sure where the best
place to put that check would be though.
Cheers,
Nathan
On Tue, Jan 12, 2021 at 4:34 AM Nathan Chancellor
[off-list ref] wrote:
On Tue, Jan 12, 2021 at 04:19:01AM +0900, Masahiro Yamada wrote:
quoted
On Tue, Jan 12, 2021 at 3:06 AM Nathan Chancellor
[off-list ref] wrote:
quoted
After commit da5fb18225b4 ("bpf: Support pre-2.25-binutils objcopy for
vmlinux BTF"), having CONFIG_DEBUG_INFO_BTF enabled but lacking a valid
copy of pahole results in a kernel that will fully compile but fail to
link. The user then has to either install pahole or disable
CONFIG_DEBUG_INFO_BTF and rebuild the kernel but only after their build
has failed, which could have been a significant amount of time depending
on the hardware.
Avoid a poor user experience and require pahole to be installed with an
appropriate version to select and use CONFIG_DEBUG_INFO_BTF, which is
standard for options that require a specific tools version.
Suggested-by: Sedat Dilek <redacted>
Signed-off-by: Nathan Chancellor <redacted>
I am not sure if this is the right direction.
I used to believe moving any tool test to the Kconfig
was the right thing to do.
For example, I tried to move the libelf test to Kconfig,
and make STACK_VALIDATION depend on it.
https://patchwork.kernel.org/project/linux-kbuild/patch/1531186516-15764-1-git-send-email-yamada.masahiro@socionext.com/
It was rejected.
In my understanding, it is good to test target toolchains
in Kconfig (e.g. cc-option, ld-option, etc).
As for host tools, in contrast, it is better to _intentionally_
break the build in order to let users know that something needed is missing.
Then, they will install necessary tools or libraries.
It is just a one-time setup, in most cases,
just running 'apt install' or 'dnf install'.
Recently, a similar thing happened to GCC_PLUGINS
https://patchwork.kernel.org/project/linux-kbuild/patch/20201203125700.161354-1-masahiroy@kernel.org/#23855673
Following this pattern, if a new pahole is not installed,
it might be better to break the build instead of hiding
the CONFIG option.
In my case, it is just a matter of 'apt install pahole'.
On some distributions, the bundled pahole is not new enough,
and people may end up with building pahole from the source code.
This is fair enough. However, I think that parts of this patch could
still be salvaged into something that fits this by making it so that if
pahole is not installed (CONFIG_PAHOLE_VERSION=0) or too old, the build
errors at the beginning, rather at the end. I am not sure where the best
place to put that check would be though.
Me neither.
Collecting tool checks to the beginning would be user-friendly.
However, scattering the related code to multiple places is not
nice from the developer point of view.
How big is it a problem if the build fails
at the very last stage?
You can install pahole, then resume "make".
Kbuild skips unneeded building, then you will
be able to come back to the last build stage shortly.
--
Best Regards
Masahiro Yamada
On Tue, Jan 12, 2021 at 04:50:50AM +0900, Masahiro Yamada wrote:
On Tue, Jan 12, 2021 at 4:34 AM Nathan Chancellor
[off-list ref] wrote:
quoted
On Tue, Jan 12, 2021 at 04:19:01AM +0900, Masahiro Yamada wrote:
quoted
On Tue, Jan 12, 2021 at 3:06 AM Nathan Chancellor
[off-list ref] wrote:
quoted
After commit da5fb18225b4 ("bpf: Support pre-2.25-binutils objcopy for
vmlinux BTF"), having CONFIG_DEBUG_INFO_BTF enabled but lacking a valid
copy of pahole results in a kernel that will fully compile but fail to
link. The user then has to either install pahole or disable
CONFIG_DEBUG_INFO_BTF and rebuild the kernel but only after their build
has failed, which could have been a significant amount of time depending
on the hardware.
Avoid a poor user experience and require pahole to be installed with an
appropriate version to select and use CONFIG_DEBUG_INFO_BTF, which is
standard for options that require a specific tools version.
Suggested-by: Sedat Dilek <redacted>
Signed-off-by: Nathan Chancellor <redacted>
I am not sure if this is the right direction.
I used to believe moving any tool test to the Kconfig
was the right thing to do.
For example, I tried to move the libelf test to Kconfig,
and make STACK_VALIDATION depend on it.
https://patchwork.kernel.org/project/linux-kbuild/patch/1531186516-15764-1-git-send-email-yamada.masahiro@socionext.com/
It was rejected.
In my understanding, it is good to test target toolchains
in Kconfig (e.g. cc-option, ld-option, etc).
As for host tools, in contrast, it is better to _intentionally_
break the build in order to let users know that something needed is missing.
Then, they will install necessary tools or libraries.
It is just a one-time setup, in most cases,
just running 'apt install' or 'dnf install'.
Recently, a similar thing happened to GCC_PLUGINS
https://patchwork.kernel.org/project/linux-kbuild/patch/20201203125700.161354-1-masahiroy@kernel.org/#23855673
Following this pattern, if a new pahole is not installed,
it might be better to break the build instead of hiding
the CONFIG option.
In my case, it is just a matter of 'apt install pahole'.
On some distributions, the bundled pahole is not new enough,
and people may end up with building pahole from the source code.
This is fair enough. However, I think that parts of this patch could
still be salvaged into something that fits this by making it so that if
pahole is not installed (CONFIG_PAHOLE_VERSION=0) or too old, the build
errors at the beginning, rather at the end. I am not sure where the best
place to put that check would be though.
Me neither.
Collecting tool checks to the beginning would be user-friendly.
However, scattering the related code to multiple places is not
nice from the developer point of view.
How big is it a problem if the build fails
at the very last stage?
You can install pahole, then resume "make".
Kbuild skips unneeded building, then you will
be able to come back to the last build stage shortly.
There will often be times where I am testing multiple configurations in
a row serially and the longer that a build takes to fail, the longer it
takes for me to get a "real" result. That is my motivation behind this
change. If people are happy with the current state of things, I will
just stick with universally disabling CONFIG_DEBUG_INFO_BTF in my test
framework.
Cheers,
Nathan
On Mon, Jan 11, 2021 at 12:00 PM Nathan Chancellor
[off-list ref] wrote:
On Tue, Jan 12, 2021 at 04:50:50AM +0900, Masahiro Yamada wrote:
quoted
On Tue, Jan 12, 2021 at 4:34 AM Nathan Chancellor
[off-list ref] wrote:
quoted
On Tue, Jan 12, 2021 at 04:19:01AM +0900, Masahiro Yamada wrote:
quoted
On Tue, Jan 12, 2021 at 3:06 AM Nathan Chancellor
[off-list ref] wrote:
quoted
After commit da5fb18225b4 ("bpf: Support pre-2.25-binutils objcopy for
vmlinux BTF"), having CONFIG_DEBUG_INFO_BTF enabled but lacking a valid
copy of pahole results in a kernel that will fully compile but fail to
link. The user then has to either install pahole or disable
CONFIG_DEBUG_INFO_BTF and rebuild the kernel but only after their build
has failed, which could have been a significant amount of time depending
on the hardware.
Avoid a poor user experience and require pahole to be installed with an
appropriate version to select and use CONFIG_DEBUG_INFO_BTF, which is
standard for options that require a specific tools version.
Suggested-by: Sedat Dilek <redacted>
Signed-off-by: Nathan Chancellor <redacted>
I am not sure if this is the right direction.
I used to believe moving any tool test to the Kconfig
was the right thing to do.
For example, I tried to move the libelf test to Kconfig,
and make STACK_VALIDATION depend on it.
https://patchwork.kernel.org/project/linux-kbuild/patch/1531186516-15764-1-git-send-email-yamada.masahiro@socionext.com/
It was rejected.
In my understanding, it is good to test target toolchains
in Kconfig (e.g. cc-option, ld-option, etc).
As for host tools, in contrast, it is better to _intentionally_
break the build in order to let users know that something needed is missing.
Then, they will install necessary tools or libraries.
It is just a one-time setup, in most cases,
just running 'apt install' or 'dnf install'.
Recently, a similar thing happened to GCC_PLUGINS
https://patchwork.kernel.org/project/linux-kbuild/patch/20201203125700.161354-1-masahiroy@kernel.org/#23855673
Following this pattern, if a new pahole is not installed,
it might be better to break the build instead of hiding
the CONFIG option.
In my case, it is just a matter of 'apt install pahole'.
On some distributions, the bundled pahole is not new enough,
and people may end up with building pahole from the source code.
This is fair enough. However, I think that parts of this patch could
still be salvaged into something that fits this by making it so that if
pahole is not installed (CONFIG_PAHOLE_VERSION=0) or too old, the build
errors at the beginning, rather at the end. I am not sure where the best
place to put that check would be though.
Me neither.
Collecting tool checks to the beginning would be user-friendly.
However, scattering the related code to multiple places is not
nice from the developer point of view.
How big is it a problem if the build fails
at the very last stage?
You can install pahole, then resume "make".
Kbuild skips unneeded building, then you will
be able to come back to the last build stage shortly.
There will often be times where I am testing multiple configurations in
a row serially and the longer that a build takes to fail, the longer it
takes for me to get a "real" result. That is my motivation behind this
change. If people are happy with the current state of things, I will
just stick with universally disabling CONFIG_DEBUG_INFO_BTF in my test
framework.
I see where Masahiro is coming from. Not seeing CONFIG_DEBUG_INFO_BTF
option because pahole is not installed (or is not new enough) is, I
believe, for the majority of users, a much bigger confusion. Currently
they will get a specific and helpful message at the link time, which
is much more actionable, IMO. Once you fix pahole dependency, running
make again would skip all the already compiled code and would start
linking almost immediately, so if you are doing build locally there is
a very little downside.
I understand your situation is a bit different in that you are
building from scratch every single time (probably some sort of CI
setup, right?). But it's a rarer and more power-user use case. And
fixing pahole dependency is a one-time fix, so it's frustrating, but
fixable on your side.
As for disabling CONFIG_DEBUG_INFO_BTF. It's up to you and depends on
what you are after, but major distros now enable it by default, so if
you want to resemble common kernel configs, it's probably better to
stick with it.
Ideally, I'd love for Kconfig to have a way to express tool
dependencies in such a way that it's still possible to choose desired
options and if the build environment is lacking dependencies then it
would be communicated early on. I have no idea if that's doable and
how much effort it'd take, though.
On Mon, Jan 11, 2021 at 7:06 PM Nathan Chancellor
[off-list ref] wrote:
After commit da5fb18225b4 ("bpf: Support pre-2.25-binutils objcopy for
vmlinux BTF"), having CONFIG_DEBUG_INFO_BTF enabled but lacking a valid
copy of pahole results in a kernel that will fully compile but fail to
link. The user then has to either install pahole or disable
CONFIG_DEBUG_INFO_BTF and rebuild the kernel but only after their build
has failed, which could have been a significant amount of time depending
on the hardware.
Avoid a poor user experience and require pahole to be installed with an
appropriate version to select and use CONFIG_DEBUG_INFO_BTF, which is
standard for options that require a specific tools version.
Suggested-by: Sedat Dilek <redacted>
Signed-off-by: Nathan Chancellor <redacted>
Thanks for the patch, Nathan,
Might be good to gave a hint to the user if pahole version does not
match requirements?
Feel free to add my:
Tested-by: Sedat Dilek <redacted>
- Sedat -
@@ -139,19 +139,6 @@ vmlinux_link()# ${2} - file to dump raw BTF data into gen_btf(){-localpahole_ver--if![-x"$(command-v${PAHOLE})"];then-echo>&2"BTF: ${1}: pahole (${PAHOLE}) is not available"-return1-fi--pahole_ver=$(${PAHOLE}--version|sed-E's/v([0-9]+)\.([0-9]+)/\1\2/')-if["${pahole_ver}"-lt"116"];then-echo>&2"BTF: ${1}: pahole version $(${PAHOLE}--version) is too old, need at least v1.16"-return1-fi-vmlinux_link${1}info"BTF"${2}
@@ -0,0 +1,16 @@+#!/bin/sh+# SPDX-License-Identifier: GPL-2.0+#+# Usage: $ ./scripts/pahole-version.sh pahole+#+# Print the pahole version as a three digit string+# such as `119' for pahole v1.19 etc.++pahole="$*"++if![-x"$(command-v$pahole)"];then+echo0+exit1+fi++$pahole--version|sed-E's/v([0-9]+)\.([0-9]+)/\1\2/'
On Mon, Jan 11, 2021 at 1:24 PM Andrii Nakryiko
[off-list ref] wrote:
On Mon, Jan 11, 2021 at 12:00 PM Nathan Chancellor
[off-list ref] wrote:
quoted
On Tue, Jan 12, 2021 at 04:50:50AM +0900, Masahiro Yamada wrote:
quoted
On Tue, Jan 12, 2021 at 4:34 AM Nathan Chancellor
[off-list ref] wrote:
quoted
On Tue, Jan 12, 2021 at 04:19:01AM +0900, Masahiro Yamada wrote:
quoted
On Tue, Jan 12, 2021 at 3:06 AM Nathan Chancellor
[off-list ref] wrote:
quoted
After commit da5fb18225b4 ("bpf: Support pre-2.25-binutils objcopy for
vmlinux BTF"), having CONFIG_DEBUG_INFO_BTF enabled but lacking a valid
copy of pahole results in a kernel that will fully compile but fail to
link. The user then has to either install pahole or disable
CONFIG_DEBUG_INFO_BTF and rebuild the kernel but only after their build
has failed, which could have been a significant amount of time depending
on the hardware.
Avoid a poor user experience and require pahole to be installed with an
appropriate version to select and use CONFIG_DEBUG_INFO_BTF, which is
standard for options that require a specific tools version.
Suggested-by: Sedat Dilek <redacted>
Signed-off-by: Nathan Chancellor <redacted>
I am not sure if this is the right direction.
I used to believe moving any tool test to the Kconfig
was the right thing to do.
For example, I tried to move the libelf test to Kconfig,
and make STACK_VALIDATION depend on it.
https://patchwork.kernel.org/project/linux-kbuild/patch/1531186516-15764-1-git-send-email-yamada.masahiro@socionext.com/
It was rejected.
In my understanding, it is good to test target toolchains
in Kconfig (e.g. cc-option, ld-option, etc).
As for host tools, in contrast, it is better to _intentionally_
break the build in order to let users know that something needed is missing.
Then, they will install necessary tools or libraries.
It is just a one-time setup, in most cases,
just running 'apt install' or 'dnf install'.
Recently, a similar thing happened to GCC_PLUGINS
https://patchwork.kernel.org/project/linux-kbuild/patch/20201203125700.161354-1-masahiroy@kernel.org/#23855673
Following this pattern, if a new pahole is not installed,
it might be better to break the build instead of hiding
the CONFIG option.
In my case, it is just a matter of 'apt install pahole'.
On some distributions, the bundled pahole is not new enough,
and people may end up with building pahole from the source code.
This is fair enough. However, I think that parts of this patch could
still be salvaged into something that fits this by making it so that if
pahole is not installed (CONFIG_PAHOLE_VERSION=0) or too old, the build
errors at the beginning, rather at the end. I am not sure where the best
place to put that check would be though.
Me neither.
Collecting tool checks to the beginning would be user-friendly.
However, scattering the related code to multiple places is not
nice from the developer point of view.
How big is it a problem if the build fails
at the very last stage?
You can install pahole, then resume "make".
Kbuild skips unneeded building, then you will
be able to come back to the last build stage shortly.
There will often be times where I am testing multiple configurations in
a row serially and the longer that a build takes to fail, the longer it
takes for me to get a "real" result. That is my motivation behind this
change. If people are happy with the current state of things, I will
just stick with universally disabling CONFIG_DEBUG_INFO_BTF in my test
framework.
I see where Masahiro is coming from. Not seeing CONFIG_DEBUG_INFO_BTF
option because pahole is not installed (or is not new enough) is, I
believe, for the majority of users, a much bigger confusion. Currently
they will get a specific and helpful message at the link time, which
is much more actionable, IMO. Once you fix pahole dependency, running
make again would skip all the already compiled code and would start
linking almost immediately, so if you are doing build locally there is
a very little downside.
I understand your situation is a bit different in that you are
building from scratch every single time (probably some sort of CI
setup, right?). But it's a rarer and more power-user use case. And
fixing pahole dependency is a one-time fix, so it's frustrating, but
fixable on your side.
As for disabling CONFIG_DEBUG_INFO_BTF. It's up to you and depends on
what you are after, but major distros now enable it by default, so if
you want to resemble common kernel configs, it's probably better to
stick with it.
Ideally, I'd love for Kconfig to have a way to express tool
dependencies in such a way that it's still possible to choose desired
options and if the build environment is lacking dependencies then it
would be communicated early on. I have no idea if that's doable and
how much effort it'd take, though.
Yes, I think that would be exactly what we want because DEBUG_INFO_BTF
could cause the build to error if PAHOLE_VERSION is not >= 116. I will
try to keep an eye on that thread to see how it goes then respin this
based on anything that comes from it.
Cheers,
Nathan
Yes, I think that would be exactly what we want because DEBUG_INFO_BTF
could cause the build to error if PAHOLE_VERSION is not >= 116. I will
try to keep an eye on that thread to see how it goes then respin this
based on anything that comes from it.
For BPF/pahole testing (see [1]) with CONFIG_DEBUG_INFO_DWARF5=y I did:
$ git diff
$(success,$(srctree)/scripts/test_dwarf5_support.sh $(CC)
$(CLANG_FLAGS))
- depends on !DEBUG_INFO_BTF
+ depends on !DEBUG_INFO_BTF || (DEBUG_INFO_BTF && PAHOLE_VERSION >= 120)
help
Generate DWARF v5 debug info. Requires binutils 2.35.2, gcc 5.0+ (gcc
5.0+ accepts the -gdwarf-5 flag but only had partial support for some
Thanks again for that patch.
- Sedat -
[1] https://git.kernel.org/pub/scm/devel/pahole/pahole.git/log/?h=tmp.1.20
On Mon, Jan 11, 2021 at 7:06 PM Nathan Chancellor
[off-list ref] wrote:
quoted hunk
After commit da5fb18225b4 ("bpf: Support pre-2.25-binutils objcopy for
vmlinux BTF"), having CONFIG_DEBUG_INFO_BTF enabled but lacking a valid
copy of pahole results in a kernel that will fully compile but fail to
link. The user then has to either install pahole or disable
CONFIG_DEBUG_INFO_BTF and rebuild the kernel but only after their build
has failed, which could have been a significant amount of time depending
on the hardware.
Avoid a poor user experience and require pahole to be installed with an
appropriate version to select and use CONFIG_DEBUG_INFO_BTF, which is
standard for options that require a specific tools version.
Suggested-by: Sedat Dilek <redacted>
Signed-off-by: Nathan Chancellor <redacted>
---
MAINTAINERS | 1 +
init/Kconfig | 4 ++++
lib/Kconfig.debug | 6 ++----
scripts/link-vmlinux.sh | 13 -------------
scripts/pahole-version.sh | 16 ++++++++++++++++
5 files changed, 23 insertions(+), 17 deletions(-)
create mode 100755 scripts/pahole-version.sh
@@ -139,19 +139,6 @@ vmlinux_link()# ${2} - file to dump raw BTF data into gen_btf(){-localpahole_ver--if![-x"$(command-v${PAHOLE})"];then-echo>&2"BTF: ${1}: pahole (${PAHOLE}) is not available"-return1-fi--pahole_ver=$(${PAHOLE}--version|sed-E's/v([0-9]+)\.([0-9]+)/\1\2/')-if["${pahole_ver}"-lt"116"];then-echo>&2"BTF: ${1}: pahole version $(${PAHOLE}--version) is too old, need at least v1.16"-return1-fi-vmlinux_link${1}info"BTF"${2}
@@ -0,0 +1,16 @@+#!/bin/sh+# SPDX-License-Identifier: GPL-2.0+#+# Usage: $ ./scripts/pahole-version.sh pahole+#+# Print the pahole version as a three digit string+# such as `119' for pahole v1.19 etc.++pahole="$*"++if![-x"$(command-v$pahole)"];then+echo0+exit1+fi++$pahole--version|sed-E's/v([0-9]+)\.([0-9]+)/\1\2/'
Cannot say if all supported pahole in the Linux kernel have that feature/option:
$ /opt/pahole/bin/pahole --numeric_version
120
- Sedat -