When CONFIG_DEBUG_INFO is enabled, the two kallsyms linking steps spend
time collecting and writing the dwarf sections to the temporary output
files. kallsyms does not need this information, and leaving it off
halves their linking time. This is especially noticeable without
CONFIG_DEBUG_INFO_REDUCED. The BTF linking stage, however, does still
need those details.
Refactor the BTF and kallsyms generation stages slightly for more
regularized temporary names. Skip debug during kallsyms links.
For a full debug info build with BTF, my link time goes from 1m06s to
0m54s, saving about 12 seconds, or 18%.
Signed-off-by: Kees Cook <[email protected]>
---
scripts/link-vmlinux.sh | 28 +++++++++++++++++++---------
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index dd484e92752e..ac569e197bfa 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -63,12 +63,18 @@ vmlinux_link()
local lds="${objtree}/${KBUILD_LDS}"
local output=${1}
local objects
+ local strip_debug
info LD ${output}
# skip output file argument
shift
+ # The kallsyms linking does not need debug symbols included.
+ if [ "$output" != "${output#.tmp_vmlinux.kallsyms}" ] ; then
+ strip_debug=-Wl,--strip-debug
+ fi
+
if [ "${SRCARCH}" != "um" ]; then
objects="--whole-archive \
${KBUILD_VMLINUX_OBJS} \
@@ -79,6 +85,7 @@ vmlinux_link()
${@}"
${LD} ${KBUILD_LDFLAGS} ${LDFLAGS_vmlinux} \
+ ${strip_debug#-Wl,} \
-o ${output} \
-T ${lds} ${objects}
else
@@ -91,6 +98,7 @@ vmlinux_link()
${@}"
${CC} ${CFLAGS_vmlinux} \
+ ${strip_debug} \
-o ${output} \
-Wl,-T,${lds} \
${objects} \
@@ -106,6 +114,8 @@ gen_btf()
{
local pahole_ver
local bin_arch
+ local bin_format
+ local bin_file
if ! [ -x "$(command -v ${PAHOLE})" ]; then
echo >&2 "BTF: ${1}: pahole (${PAHOLE}) is not available"
@@ -118,8 +128,9 @@ gen_btf()
return 1
fi
- info "BTF" ${2}
vmlinux_link ${1}
+
+ info "BTF" ${2}
LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1}
# dump .BTF section into raw binary file to link with final vmlinux
@@ -127,11 +138,12 @@ gen_btf()
cut -d, -f1 | cut -d' ' -f2)
bin_format=$(LANG=C ${OBJDUMP} -f ${1} | grep 'file format' | \
awk '{print $4}')
+ bin_file=.btf.vmlinux.bin
${OBJCOPY} --change-section-address .BTF=0 \
--set-section-flags .BTF=alloc -O binary \
- --only-section=.BTF ${1} .btf.vmlinux.bin
+ --only-section=.BTF ${1} $bin_file
${OBJCOPY} -I binary -O ${bin_format} -B ${bin_arch} \
- --rename-section .data=.BTF .btf.vmlinux.bin ${2}
+ --rename-section .data=.BTF $bin_file ${2}
}
# Create ${2} .o file with all symbols from the ${1} object file
@@ -166,8 +178,8 @@ kallsyms()
kallsyms_step()
{
kallsymso_prev=${kallsymso}
- kallsymso=.tmp_kallsyms${1}.o
- kallsyms_vmlinux=.tmp_vmlinux${1}
+ kallsyms_vmlinux=.tmp_vmlinux.kallsyms${1}
+ kallsymso=${kallsyms_vmlinux}.o
vmlinux_link ${kallsyms_vmlinux} "${kallsymso_prev}" ${btf_vmlinux_bin_o}
kallsyms ${kallsyms_vmlinux} ${kallsymso}
@@ -190,7 +202,6 @@ cleanup()
{
rm -f .btf.*
rm -f .tmp_System.map
- rm -f .tmp_kallsyms*
rm -f .tmp_vmlinux*
rm -f System.map
rm -f vmlinux
@@ -257,9 +268,8 @@ tr '\0' '\n' < modules.builtin.modinfo | sed -n 's/^[[:alnum:]:_]*\.file=//p' |
btf_vmlinux_bin_o=""
if [ -n "${CONFIG_DEBUG_INFO_BTF}" ]; then
- if gen_btf .tmp_vmlinux.btf .btf.vmlinux.bin.o ; then
- btf_vmlinux_bin_o=.btf.vmlinux.bin.o
- else
+ btf_vmlinux_bin_o=.btf.vmlinux.bin.o
+ if ! gen_btf .tmp_vmlinux.btf $btf_vmlinux_bin_o ; then
echo >&2 "Failed to generate BTF for vmlinux"
echo >&2 "Try to disable CONFIG_DEBUG_INFO_BTF"
exit 1
--
2.20.1
--
Kees Cook
On Mon, Feb 24, 2020 at 09:16:17PM -0800, Kees Cook wrote:
> When CONFIG_DEBUG_INFO is enabled, the two kallsyms linking steps spend
> time collecting and writing the dwarf sections to the temporary output
> files. kallsyms does not need this information, and leaving it off
> halves their linking time. This is especially noticeable without
> CONFIG_DEBUG_INFO_REDUCED. The BTF linking stage, however, does still
> need those details.
>
> Refactor the BTF and kallsyms generation stages slightly for more
> regularized temporary names. Skip debug during kallsyms links.
>
> For a full debug info build with BTF, my link time goes from 1m06s to
> 0m54s, saving about 12 seconds, or 18%.
>
> Signed-off-by: Kees Cook <[email protected]>
Ping. Masahiro what do you think of this? It saves me a fair bit of time
on the link stage... I bet the BPF folks would be interested too. :)
-Kees
> ---
> scripts/link-vmlinux.sh | 28 +++++++++++++++++++---------
> 1 file changed, 19 insertions(+), 9 deletions(-)
>
> diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
> index dd484e92752e..ac569e197bfa 100755
> --- a/scripts/link-vmlinux.sh
> +++ b/scripts/link-vmlinux.sh
> @@ -63,12 +63,18 @@ vmlinux_link()
> local lds="${objtree}/${KBUILD_LDS}"
> local output=${1}
> local objects
> + local strip_debug
>
> info LD ${output}
>
> # skip output file argument
> shift
>
> + # The kallsyms linking does not need debug symbols included.
> + if [ "$output" != "${output#.tmp_vmlinux.kallsyms}" ] ; then
> + strip_debug=-Wl,--strip-debug
> + fi
> +
> if [ "${SRCARCH}" != "um" ]; then
> objects="--whole-archive \
> ${KBUILD_VMLINUX_OBJS} \
> @@ -79,6 +85,7 @@ vmlinux_link()
> ${@}"
>
> ${LD} ${KBUILD_LDFLAGS} ${LDFLAGS_vmlinux} \
> + ${strip_debug#-Wl,} \
> -o ${output} \
> -T ${lds} ${objects}
> else
> @@ -91,6 +98,7 @@ vmlinux_link()
> ${@}"
>
> ${CC} ${CFLAGS_vmlinux} \
> + ${strip_debug} \
> -o ${output} \
> -Wl,-T,${lds} \
> ${objects} \
> @@ -106,6 +114,8 @@ gen_btf()
> {
> local pahole_ver
> local bin_arch
> + local bin_format
> + local bin_file
>
> if ! [ -x "$(command -v ${PAHOLE})" ]; then
> echo >&2 "BTF: ${1}: pahole (${PAHOLE}) is not available"
> @@ -118,8 +128,9 @@ gen_btf()
> return 1
> fi
>
> - info "BTF" ${2}
> vmlinux_link ${1}
> +
> + info "BTF" ${2}
> LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1}
>
> # dump .BTF section into raw binary file to link with final vmlinux
> @@ -127,11 +138,12 @@ gen_btf()
> cut -d, -f1 | cut -d' ' -f2)
> bin_format=$(LANG=C ${OBJDUMP} -f ${1} | grep 'file format' | \
> awk '{print $4}')
> + bin_file=.btf.vmlinux.bin
> ${OBJCOPY} --change-section-address .BTF=0 \
> --set-section-flags .BTF=alloc -O binary \
> - --only-section=.BTF ${1} .btf.vmlinux.bin
> + --only-section=.BTF ${1} $bin_file
> ${OBJCOPY} -I binary -O ${bin_format} -B ${bin_arch} \
> - --rename-section .data=.BTF .btf.vmlinux.bin ${2}
> + --rename-section .data=.BTF $bin_file ${2}
> }
>
> # Create ${2} .o file with all symbols from the ${1} object file
> @@ -166,8 +178,8 @@ kallsyms()
> kallsyms_step()
> {
> kallsymso_prev=${kallsymso}
> - kallsymso=.tmp_kallsyms${1}.o
> - kallsyms_vmlinux=.tmp_vmlinux${1}
> + kallsyms_vmlinux=.tmp_vmlinux.kallsyms${1}
> + kallsymso=${kallsyms_vmlinux}.o
>
> vmlinux_link ${kallsyms_vmlinux} "${kallsymso_prev}" ${btf_vmlinux_bin_o}
> kallsyms ${kallsyms_vmlinux} ${kallsymso}
> @@ -190,7 +202,6 @@ cleanup()
> {
> rm -f .btf.*
> rm -f .tmp_System.map
> - rm -f .tmp_kallsyms*
> rm -f .tmp_vmlinux*
> rm -f System.map
> rm -f vmlinux
> @@ -257,9 +268,8 @@ tr '\0' '\n' < modules.builtin.modinfo | sed -n 's/^[[:alnum:]:_]*\.file=//p' |
>
> btf_vmlinux_bin_o=""
> if [ -n "${CONFIG_DEBUG_INFO_BTF}" ]; then
> - if gen_btf .tmp_vmlinux.btf .btf.vmlinux.bin.o ; then
> - btf_vmlinux_bin_o=.btf.vmlinux.bin.o
> - else
> + btf_vmlinux_bin_o=.btf.vmlinux.bin.o
> + if ! gen_btf .tmp_vmlinux.btf $btf_vmlinux_bin_o ; then
> echo >&2 "Failed to generate BTF for vmlinux"
> echo >&2 "Try to disable CONFIG_DEBUG_INFO_BTF"
> exit 1
> --
> 2.20.1
>
>
> --
> Kees Cook
--
Kees Cook
On Mon, Mar 2, 2020 at 8:48 PM Kees Cook <[email protected]> wrote:
>
> On Mon, Feb 24, 2020 at 09:16:17PM -0800, Kees Cook wrote:
> > When CONFIG_DEBUG_INFO is enabled, the two kallsyms linking steps spend
> > time collecting and writing the dwarf sections to the temporary output
> > files. kallsyms does not need this information, and leaving it off
> > halves their linking time. This is especially noticeable without
> > CONFIG_DEBUG_INFO_REDUCED. The BTF linking stage, however, does still
> > need those details.
> >
> > Refactor the BTF and kallsyms generation stages slightly for more
> > regularized temporary names. Skip debug during kallsyms links.
> >
> > For a full debug info build with BTF, my link time goes from 1m06s to
> > 0m54s, saving about 12 seconds, or 18%.
> >
> > Signed-off-by: Kees Cook <[email protected]>
>
> Ping. Masahiro what do you think of this? It saves me a fair bit of time
> on the link stage... I bet the BPF folks would be interested too. :)
The build time improvement sound great.
Could you please resubmit for bpf-next tree?
So we can test and apply properly?
Thanks!
On Mon, Feb 24, 2020 at 9:17 PM Kees Cook <[email protected]> wrote:
>
> When CONFIG_DEBUG_INFO is enabled, the two kallsyms linking steps spend
> time collecting and writing the dwarf sections to the temporary output
> files. kallsyms does not need this information, and leaving it off
> halves their linking time. This is especially noticeable without
> CONFIG_DEBUG_INFO_REDUCED. The BTF linking stage, however, does still
> need those details.
>
> Refactor the BTF and kallsyms generation stages slightly for more
> regularized temporary names. Skip debug during kallsyms links.
>
> For a full debug info build with BTF, my link time goes from 1m06s to
> 0m54s, saving about 12 seconds, or 18%.
>
> Signed-off-by: Kees Cook <[email protected]>
> ---
I've tested locally, seems to be generating BTF properly (I haven't
timed anything, though). See nit below, but otherwise:
Acked-by: Andrii Nakryiko <[email protected]>
> scripts/link-vmlinux.sh | 28 +++++++++++++++++++---------
> 1 file changed, 19 insertions(+), 9 deletions(-)
>
[...]
> @@ -106,6 +114,8 @@ gen_btf()
> {
> local pahole_ver
> local bin_arch
> + local bin_format
> + local bin_file
>
> if ! [ -x "$(command -v ${PAHOLE})" ]; then
> echo >&2 "BTF: ${1}: pahole (${PAHOLE}) is not available"
> @@ -118,8 +128,9 @@ gen_btf()
> return 1
> fi
>
> - info "BTF" ${2}
> vmlinux_link ${1}
> +
> + info "BTF" ${2}
Any reason to exclude linking from "BTF" step? It's still a part of
BTF generation, so seems fair to have BTF encompass both vmlinux
linking and BTF generation/deduplication?
> LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1}
>
> # dump .BTF section into raw binary file to link with final vmlinux
[...]
On Mon, Mar 02, 2020 at 10:55:04PM -0800, Andrii Nakryiko wrote:
> On Mon, Feb 24, 2020 at 9:17 PM Kees Cook <[email protected]> wrote:
> >
> > When CONFIG_DEBUG_INFO is enabled, the two kallsyms linking steps spend
> > time collecting and writing the dwarf sections to the temporary output
> > files. kallsyms does not need this information, and leaving it off
> > halves their linking time. This is especially noticeable without
> > CONFIG_DEBUG_INFO_REDUCED. The BTF linking stage, however, does still
> > need those details.
> >
> > Refactor the BTF and kallsyms generation stages slightly for more
> > regularized temporary names. Skip debug during kallsyms links.
> >
> > For a full debug info build with BTF, my link time goes from 1m06s to
> > 0m54s, saving about 12 seconds, or 18%.
> >
> > Signed-off-by: Kees Cook <[email protected]>
> > ---
>
> I've tested locally, seems to be generating BTF properly (I haven't
> timed anything, though). See nit below, but otherwise:
>
> Acked-by: Andrii Nakryiko <[email protected]>
Thanks!
>
> > scripts/link-vmlinux.sh | 28 +++++++++++++++++++---------
> > 1 file changed, 19 insertions(+), 9 deletions(-)
> >
>
> [...]
>
> > @@ -106,6 +114,8 @@ gen_btf()
> > {
> > local pahole_ver
> > local bin_arch
> > + local bin_format
> > + local bin_file
> >
> > if ! [ -x "$(command -v ${PAHOLE})" ]; then
> > echo >&2 "BTF: ${1}: pahole (${PAHOLE}) is not available"
> > @@ -118,8 +128,9 @@ gen_btf()
> > return 1
> > fi
> >
> > - info "BTF" ${2}
> > vmlinux_link ${1}
> > +
> > + info "BTF" ${2}
>
> Any reason to exclude linking from "BTF" step? It's still a part of
> BTF generation, so seems fair to have BTF encompass both vmlinux
> linking and BTF generation/deduplication?
I'm not sure I'm following what you're saying here. If you're asking why
BTF linking is separate from the final vmlinux link, it's because of how
kallsyms is generated. Currently it's using a rather brute-force
approach to figure out exactly where everything is going to be in the
final link, and for that it need to have both the BTF symbols present
and the kallysms symbols present. So, unfortunately, each needs to be a
separate step. I spent some time trying to merge BTF and kallsyms phase
1, but I didn't find a viable solution. I'm *sure* there is a better way
to handle kallsyms, but I haven't had the time to really investigate it.
I think it would require some close coordination with linker behavior
changes...
>
> > LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1}
> >
> > # dump .BTF section into raw binary file to link with final vmlinux
BTW, in looking at BTF generation, why is this cut up into three steps:
pahole, objcopy, objcopy... shouldn't pahole just gross an output method
to dump the final .o file? That would be MUCH nicer. Especially since
the first step ends up rewriting (?!) the original ELF. This is a lot of
needless IO...
--
Kees Cook
On Tue, Mar 3, 2020 at 1:06 PM Kees Cook <[email protected]> wrote:
>
> On Mon, Mar 02, 2020 at 10:55:04PM -0800, Andrii Nakryiko wrote:
> > On Mon, Feb 24, 2020 at 9:17 PM Kees Cook <[email protected]> wrote:
> > >
> > > When CONFIG_DEBUG_INFO is enabled, the two kallsyms linking steps spend
> > > time collecting and writing the dwarf sections to the temporary output
> > > files. kallsyms does not need this information, and leaving it off
> > > halves their linking time. This is especially noticeable without
> > > CONFIG_DEBUG_INFO_REDUCED. The BTF linking stage, however, does still
> > > need those details.
> > >
> > > Refactor the BTF and kallsyms generation stages slightly for more
> > > regularized temporary names. Skip debug during kallsyms links.
> > >
> > > For a full debug info build with BTF, my link time goes from 1m06s to
> > > 0m54s, saving about 12 seconds, or 18%.
> > >
> > > Signed-off-by: Kees Cook <[email protected]>
> > > ---
> >
> > I've tested locally, seems to be generating BTF properly (I haven't
> > timed anything, though). See nit below, but otherwise:
> >
> > Acked-by: Andrii Nakryiko <[email protected]>
>
> Thanks!
>
> >
> > > scripts/link-vmlinux.sh | 28 +++++++++++++++++++---------
> > > 1 file changed, 19 insertions(+), 9 deletions(-)
> > >
> >
> > [...]
> >
> > > @@ -106,6 +114,8 @@ gen_btf()
> > > {
> > > local pahole_ver
> > > local bin_arch
> > > + local bin_format
> > > + local bin_file
> > >
> > > if ! [ -x "$(command -v ${PAHOLE})" ]; then
> > > echo >&2 "BTF: ${1}: pahole (${PAHOLE}) is not available"
> > > @@ -118,8 +128,9 @@ gen_btf()
> > > return 1
> > > fi
> > >
> > > - info "BTF" ${2}
> > > vmlinux_link ${1}
> > > +
> > > + info "BTF" ${2}
> >
> > Any reason to exclude linking from "BTF" step? It's still a part of
> > BTF generation, so seems fair to have BTF encompass both vmlinux
> > linking and BTF generation/deduplication?
>
> I'm not sure I'm following what you're saying here. If you're asking why
> BTF linking is separate from the final vmlinux link, it's because of how
> kallsyms is generated. Currently it's using a rather brute-force
No, I meant that you moved `info "BTF"` to after `vmlinux_link` call,
which will make it appear (from make output) as if BTF generation
phase is shorter than it is. No big deal, was just wondering if it was
done on purpose.
> approach to figure out exactly where everything is going to be in the
> final link, and for that it need to have both the BTF symbols present
> and the kallysms symbols present. So, unfortunately, each needs to be a
> separate step. I spent some time trying to merge BTF and kallsyms phase
> 1, but I didn't find a viable solution. I'm *sure* there is a better way
> to handle kallsyms, but I haven't had the time to really investigate it.
> I think it would require some close coordination with linker behavior
> changes...
>
> >
> > > LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1}
> > >
> > > # dump .BTF section into raw binary file to link with final vmlinux
>
> BTW, in looking at BTF generation, why is this cut up into three steps:
> pahole, objcopy, objcopy... shouldn't pahole just gross an output method
> to dump the final .o file? That would be MUCH nicer. Especially since
> the first step ends up rewriting (?!) the original ELF. This is a lot of
> needless IO...
Just mostly historical reasons, that was the interface pahole already
supported. I agree that it's a good idea to teach pahole to just emit
a binary BTF section dump.
>
> --
> Kees Cook
On Tue, Mar 03, 2020 at 01:50:52PM -0800, Andrii Nakryiko wrote:
> On Tue, Mar 3, 2020 at 1:06 PM Kees Cook <[email protected]> wrote:
> >
> > On Mon, Mar 02, 2020 at 10:55:04PM -0800, Andrii Nakryiko wrote:
> > > On Mon, Feb 24, 2020 at 9:17 PM Kees Cook <[email protected]> wrote:
> > > > [...]
> > > > @@ -118,8 +128,9 @@ gen_btf()
> > > > return 1
> > > > fi
> > > >
> > > > - info "BTF" ${2}
> > > > vmlinux_link ${1}
> > > > +
> > > > + info "BTF" ${2}
> > >
> > > Any reason to exclude linking from "BTF" step? It's still a part of
> > > BTF generation, so seems fair to have BTF encompass both vmlinux
> > > linking and BTF generation/deduplication?
> >
> > I'm not sure I'm following what you're saying here. If you're asking why
> > BTF linking is separate from the final vmlinux link, it's because of how
> > kallsyms is generated. Currently it's using a rather brute-force
>
> No, I meant that you moved `info "BTF"` to after `vmlinux_link` call,
> which will make it appear (from make output) as if BTF generation
> phase is shorter than it is. No big deal, was just wondering if it was
> done on purpose.
Oh! Yes. I changed the reporting in commit 8959e39272d6 ("kbuild:
Parameterize kallsyms generation and correct reporting") so that
vmlinux_link reports the "info LD ..." line instead of each of the callers.
This current patch adjusts it so "info BTF ..." is reported for the BTF
generation stage (right now there's no delay between "info BTF ..." and
"info LD ...", and it looks like the "info LD" stages takes way too
long. ;)
> > approach to figure out exactly where everything is going to be in the
> > final link, and for that it need to have both the BTF symbols present
> > and the kallysms symbols present. So, unfortunately, each needs to be a
> > separate step. I spent some time trying to merge BTF and kallsyms phase
> > 1, but I didn't find a viable solution. I'm *sure* there is a better way
> > to handle kallsyms, but I haven't had the time to really investigate it.
> > I think it would require some close coordination with linker behavior
> > changes...
> >
> > >
> > > > LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1}
> > > >
> > > > # dump .BTF section into raw binary file to link with final vmlinux
> >
> > BTW, in looking at BTF generation, why is this cut up into three steps:
> > pahole, objcopy, objcopy... shouldn't pahole just gross an output method
> > to dump the final .o file? That would be MUCH nicer. Especially since
> > the first step ends up rewriting (?!) the original ELF. This is a lot of
> > needless IO...
>
> Just mostly historical reasons, that was the interface pahole already
> supported. I agree that it's a good idea to teach pahole to just emit
> a binary BTF section dump.
/me adds it to giant TODO list ;)
--
Kees Cook
On Tue, Mar 3, 2020 at 6:11 PM Kees Cook <[email protected]> wrote:
>
> On Tue, Mar 03, 2020 at 01:50:52PM -0800, Andrii Nakryiko wrote:
> > On Tue, Mar 3, 2020 at 1:06 PM Kees Cook <[email protected]> wrote:
> > >
> > > On Mon, Mar 02, 2020 at 10:55:04PM -0800, Andrii Nakryiko wrote:
> > > > On Mon, Feb 24, 2020 at 9:17 PM Kees Cook <[email protected]> wrote:
> > > > > [...]
> > > > > @@ -118,8 +128,9 @@ gen_btf()
> > > > > return 1
> > > > > fi
> > > > >
> > > > > - info "BTF" ${2}
> > > > > vmlinux_link ${1}
> > > > > +
> > > > > + info "BTF" ${2}
> > > >
> > > > Any reason to exclude linking from "BTF" step? It's still a part of
> > > > BTF generation, so seems fair to have BTF encompass both vmlinux
> > > > linking and BTF generation/deduplication?
> > >
> > > I'm not sure I'm following what you're saying here. If you're asking why
> > > BTF linking is separate from the final vmlinux link, it's because of how
> > > kallsyms is generated. Currently it's using a rather brute-force
> >
> > No, I meant that you moved `info "BTF"` to after `vmlinux_link` call,
> > which will make it appear (from make output) as if BTF generation
> > phase is shorter than it is. No big deal, was just wondering if it was
> > done on purpose.
>
> Oh! Yes. I changed the reporting in commit 8959e39272d6 ("kbuild:
> Parameterize kallsyms generation and correct reporting") so that
> vmlinux_link reports the "info LD ..." line instead of each of the callers.
>
> This current patch adjusts it so "info BTF ..." is reported for the BTF
> generation stage (right now there's no delay between "info BTF ..." and
> "info LD ...", and it looks like the "info LD" stages takes way too
> long. ;)
Ah, I see, got it!
>
> > > approach to figure out exactly where everything is going to be in the
> > > final link, and for that it need to have both the BTF symbols present
> > > and the kallysms symbols present. So, unfortunately, each needs to be a
> > > separate step. I spent some time trying to merge BTF and kallsyms phase
> > > 1, but I didn't find a viable solution. I'm *sure* there is a better way
> > > to handle kallsyms, but I haven't had the time to really investigate it.
> > > I think it would require some close coordination with linker behavior
> > > changes...
> > >
> > > >
> > > > > LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1}
> > > > >
> > > > > # dump .BTF section into raw binary file to link with final vmlinux
> > >
> > > BTW, in looking at BTF generation, why is this cut up into three steps:
> > > pahole, objcopy, objcopy... shouldn't pahole just gross an output method
> > > to dump the final .o file? That would be MUCH nicer. Especially since
> > > the first step ends up rewriting (?!) the original ELF. This is a lot of
> > > needless IO...
> >
> > Just mostly historical reasons, that was the interface pahole already
> > supported. I agree that it's a good idea to teach pahole to just emit
> > a binary BTF section dump.
>
> /me adds it to giant TODO list ;)
>
> --
> Kees Cook
Em Tue, Mar 03, 2020 at 08:29:39PM -0800, Andrii Nakryiko escreveu:
> On Tue, Mar 3, 2020 at 6:11 PM Kees Cook <[email protected]> wrote:
> > On Tue, Mar 03, 2020 at 01:50:52PM -0800, Andrii Nakryiko wrote:
> > > On Tue, Mar 3, 2020 at 1:06 PM Kees Cook <[email protected]> wrote:
> > > > On Mon, Mar 02, 2020 at 10:55:04PM -0800, Andrii Nakryiko wrote:
> > > > > On Mon, Feb 24, 2020 at 9:17 PM Kees Cook <[email protected]> wrote:
> > > > > > LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1}
> > > > > >
> > > > > > # dump .BTF section into raw binary file to link with final vmlinux
> > > > BTW, in looking at BTF generation, why is this cut up into three steps:
> > > > pahole, objcopy, objcopy... shouldn't pahole just gross an output method
> > > > to dump the final .o file? That would be MUCH nicer. Especially since
> > > > the first step ends up rewriting (?!) the original ELF. This is a lot of
> > > > needless IO...
> > > Just mostly historical reasons, that was the interface pahole already
> > > supported. I agree that it's a good idea to teach pahole to just emit
> > > a binary BTF section dump.
> > /me adds it to giant TODO list ;)
Mine is giant as well, but adding it anyway...
:-)
- Arnaldo