This patch moves common code to utils.c file. Code from this file will
be reused across check.c and mcount.c (will be introduced in the coming
patches). Also, ensure that this change works well with existing
commands.
Signed-off-by: Sathvika Vasireddy <redacted>
---
tools/objtool/Build | 1 +
tools/objtool/check.c | 178 +-----------------------
tools/objtool/include/objtool/check.h | 2 -
tools/objtool/include/objtool/utils.h | 28 ++++
tools/objtool/orc_gen.c | 1 +
tools/objtool/utils.c | 192 ++++++++++++++++++++++++++
6 files changed, 223 insertions(+), 179 deletions(-)
create mode 100644 tools/objtool/include/objtool/utils.h
create mode 100644 tools/objtool/utils.c
This patch adds 'mcount' as a subcommand to objtool, and enables
the same for x86. objtool is built if CONFIG_FTRACE_MCOUNT_USE_OBJTOOL
is selected. Additionally, architectures can select HAVE_NOP_MCOUNT
if they choose to nop out mcount call sites. If that config option is
selected, then --mnop is passed as an option to 'objtool mcount'
Signed-off-by: Sathvika Vasireddy <redacted>
---
Makefile | 6 ++
arch/x86/Kconfig | 3 +-
scripts/Makefile.build | 12 +++
tools/objtool/Build | 2 +
tools/objtool/Makefile | 4 +-
tools/objtool/builtin-mcount.c | 74 +++++++++++++
tools/objtool/include/objtool/builtin.h | 4 +-
tools/objtool/include/objtool/objtool.h | 1 +
tools/objtool/mcount.c | 138 ++++++++++++++++++++++++
tools/objtool/objtool.c | 1 +
tools/objtool/weak.c | 5 +
11 files changed, 247 insertions(+), 3 deletions(-)
create mode 100644 tools/objtool/builtin-mcount.c
create mode 100644 tools/objtool/mcount.c
@@ -179,11 +179,29 @@ int create_mcount_loc_sections(struct objtool_file *file)loc=(unsignedlong*)sec->data->d_buf+idx;memset(loc,0,sizeof(unsignedlong));-if(elf_add_reloc_to_insn(file->elf,sec,-idx*sizeof(unsignedlong),-R_X86_64_64,-insn->sec,insn->offset))-return-1;+if(file->elf->ehdr.e_machine==EM_X86_64){+if(elf_add_reloc_to_insn(file->elf,sec,+idx*sizeof(unsignedlong),+R_X86_64_64,+insn->sec,insn->offset))+return-1;+}++if(file->elf->ehdr.e_machine==EM_PPC64){+if(elf_add_reloc_to_insn(file->elf,sec,+idx*sizeof(unsignedlong),+R_PPC64_ADDR64,+insn->sec,insn->offset))+return-1;+}++if(file->elf->ehdr.e_machine==EM_PPC){+if(elf_add_reloc_to_insn(file->elf,sec,+idx*sizeof(unsignedlong),+R_PPC_ADDR32,+insn->sec,insn->offset))+return-1;+}
It appears to me that repeating this code 3 times doesn't really scale
well, how about we introduce a helper like:
int elf_reloc_type_long(struct elf *elf)
{
switch (elf->ehdr.e_machine) {
case EM_X86_64:
return R_X86_64_64;
case EM_PPC64:
return R_PPC64_ADDR64;
case EM_PPC:
return R_PPC_ADDR32;
default:
WARN("unknown machine...")
exit(-1);
}
}
if (elf_add_reloc_to_insn(file->elf, sec,
idx * sizeof(unsigned long),
elf_reloc_type_long(file->elf),
insn->sec, insn->offset))
return -1;
On Fri, Mar 18, 2022 at 04:21:37PM +0530, Sathvika Vasireddy wrote:
This patchset adds support to implement 'objtool mcount' command.
Right now, objtool is built if CONFIG_STACK_VALIDATION is enabled.
And, '__mcount_loc' section is generated by objtool when --mcount
option is passed to check sub-command.
For architectures to be able to generate '__mcount_loc' section
without having to do stack validation, introduce 'mcount' as
a sub-command to objtool. This way, objtool is built for mcount
if CONFIG_FTRACE_MCOUNT_USE_OBJTOOL is enabled. Additionally,
architectures can select HAVE_NOP_MCOUNT to be able to nop out
mcount call sites.
TODO: Enable "objtool mcount" for clang LTO builds.
Sathvika Vasireddy (3):
objtool: Move common code to utils.c
objtool: Enable and implement 'mcount' subcommand
objtool/mcount: Add powerpc specific functions
Hi Sathvika,
Thanks for the patches!
I have some other patches in progress which will rework the objtool
interface by modularizing the cmdline options, so that each option can
be specified either individually or in combination. Even stack
validation itself will be its own separate option.
I think it will help your situation as well: "objtool run --mcount" will
only do '__mcount_loc' generation and nothing else.
Something like so:
$ ./objtool run --help
Usage: objtool run [<options>] file.o
Commands (at least one required):
-a, --uaccess validate uaccess
-c, --static-call annotate static calls
-i, --ibt validate and annotate IBT
-m, --mcount generate '__mcount_loc' section
-n, --noinstr validate noinstr
-o, --orc generate ORC metadata
-r, --retpoline validate retpoline usage
-S, --sls validate straight-line-speculation mitigation
-s, --stack-val validate stack metadata
Options:
--backtrace unwind on error
--backup create .orig files before modification
--dry-run don't write the modifications
--fp object uses frame pointers
--module object will be part of a kernel module
--no-unreachable skip 'unreachable instruction' warnings
--stats print statistics
--vmlinux object is vmlinux.o
Hopefully I'll have the patches ready soon.
--
Josh
@@ -179,11 +179,29 @@ int create_mcount_loc_sections(struct objtool_file *file)loc=(unsignedlong*)sec->data->d_buf+idx;memset(loc,0,sizeof(unsignedlong));-if(elf_add_reloc_to_insn(file->elf,sec,-idx*sizeof(unsignedlong),-R_X86_64_64,-insn->sec,insn->offset))-return-1;+if(file->elf->ehdr.e_machine==EM_X86_64){+if(elf_add_reloc_to_insn(file->elf,sec,+idx*sizeof(unsignedlong),+R_X86_64_64,+insn->sec,insn->offset))+return-1;+}++if(file->elf->ehdr.e_machine==EM_PPC64){+if(elf_add_reloc_to_insn(file->elf,sec,+idx*sizeof(unsignedlong),+R_PPC64_ADDR64,+insn->sec,insn->offset))+return-1;+}++if(file->elf->ehdr.e_machine==EM_PPC){+if(elf_add_reloc_to_insn(file->elf,sec,+idx*sizeof(unsignedlong),+R_PPC_ADDR32,+insn->sec,insn->offset))+return-1;+}
It appears to me that repeating this code 3 times doesn't really scale
well, how about we introduce a helper like:
int elf_reloc_type_long(struct elf *elf)
{
switch (elf->ehdr.e_machine) {
case EM_X86_64:
return R_X86_64_64;
case EM_PPC64:
return R_PPC64_ADDR64;
case EM_PPC:
return R_PPC_ADDR32;
default:
WARN("unknown machine...")
exit(-1);
}
}
if (elf_add_reloc_to_insn(file->elf, sec,
idx * sizeof(unsigned long),
elf_reloc_type_long(file->elf),
insn->sec, insn->offset))
return -1;
Good point. I suppose we'll need a similar helper, say,
elf_reloc_type_none(), to replace R_NONE usage if we want to have
objtool work for cross-arch builds.
- Naveen
Le 18/03/2022 à 11:51, Sathvika Vasireddy a écrit :
quoted hunk
This patch adds 'mcount' as a subcommand to objtool, and enables
the same for x86. objtool is built if CONFIG_FTRACE_MCOUNT_USE_OBJTOOL
is selected. Additionally, architectures can select HAVE_NOP_MCOUNT
if they choose to nop out mcount call sites. If that config option is
selected, then --mnop is passed as an option to 'objtool mcount'
Signed-off-by: Sathvika Vasireddy <redacted>
---
Makefile | 6 ++
arch/x86/Kconfig | 3 +-
scripts/Makefile.build | 12 +++
tools/objtool/Build | 2 +
tools/objtool/Makefile | 4 +-
tools/objtool/builtin-mcount.c | 74 +++++++++++++
tools/objtool/include/objtool/builtin.h | 4 +-
tools/objtool/include/objtool/objtool.h | 1 +
tools/objtool/mcount.c | 138 ++++++++++++++++++++++++
tools/objtool/objtool.c | 1 +
tools/objtool/weak.c | 5 +
11 files changed, 247 insertions(+), 3 deletions(-)
create mode 100644 tools/objtool/builtin-mcount.c
create mode 100644 tools/objtool/mcount.c
On PPC64 we randomly get:
/bin/sh: 1: ./tools/objtool/objtool: not found
make[2]: *** [arch/powerpc/kernel/vdso/vgettimeofday-64.o] Error 127
/linux/arch/powerpc/kernel/vdso/Makefile:77: recipe for target
'arch/powerpc/kernel/vdso/vgettimeofday-64.o' failed
make[2]: *** Deleting file 'arch/powerpc/kernel/vdso/vgettimeofday-64.o'
make[1]: *** [vdso_prepare] Error 2
make[1]: *** Waiting for unfinished jobs....
/linux/arch/powerpc/Makefile:423: recipe for target 'vdso_prepare' failed
make: *** [__sub-make] Error 2
Makefile:219: recipe for target '__sub-make' failed
This is linkely because prepare: target depends on vdso_prepare and
prepare: target depends on objtool, but vdso_prepare: doesn't depend on
objtool.
I'm not sure it is correct to run objtool mcount on VDSO as it is kind
of useless. Only VDSO64 seems to call objtool, not VDSO32.
Christophe
On PPC32 I get :
[ 0.000000] ftrace: No functions to be traced?
Without this series I get:
[ 0.000000] ftrace: allocating 22508 entries in 17 pages
[ 0.000000] ftrace: allocated 17 pages with 2 groups
Christophe
From: Naveen N. Rao <hidden> Date: 2022-03-21 08:20:09
Christophe Leroy wrote:
Le 18/03/2022 à 11:51, Sathvika Vasireddy a écrit :
quoted
This patch adds 'mcount' as a subcommand to objtool, and enables
the same for x86. objtool is built if CONFIG_FTRACE_MCOUNT_USE_OBJTOOL
is selected. Additionally, architectures can select HAVE_NOP_MCOUNT
if they choose to nop out mcount call sites. If that config option is
selected, then --mnop is passed as an option to 'objtool mcount'
Signed-off-by: Sathvika Vasireddy <redacted>
---
Makefile | 6 ++
arch/x86/Kconfig | 3 +-
scripts/Makefile.build | 12 +++
tools/objtool/Build | 2 +
tools/objtool/Makefile | 4 +-
tools/objtool/builtin-mcount.c | 74 +++++++++++++
tools/objtool/include/objtool/builtin.h | 4 +-
tools/objtool/include/objtool/objtool.h | 1 +
tools/objtool/mcount.c | 138 ++++++++++++++++++++++++
tools/objtool/objtool.c | 1 +
tools/objtool/weak.c | 5 +
11 files changed, 247 insertions(+), 3 deletions(-)
create mode 100644 tools/objtool/builtin-mcount.c
create mode 100644 tools/objtool/mcount.c
Le 18/03/2022 à 11:51, Sathvika Vasireddy a écrit :
quoted
This patch adds 'mcount' as a subcommand to objtool, and enables
the same for x86. objtool is built if CONFIG_FTRACE_MCOUNT_USE_OBJTOOL
is selected. Additionally, architectures can select HAVE_NOP_MCOUNT
if they choose to nop out mcount call sites. If that config option is
selected, then --mnop is passed as an option to 'objtool mcount'
Signed-off-by: Sathvika Vasireddy <redacted>
---
Makefile | 6 ++
arch/x86/Kconfig | 3 +-
scripts/Makefile.build | 12 +++
tools/objtool/Build | 2 +
tools/objtool/Makefile | 4 +-
tools/objtool/builtin-mcount.c | 74 +++++++++++++
tools/objtool/include/objtool/builtin.h | 4 +-
tools/objtool/include/objtool/objtool.h | 1 +
tools/objtool/mcount.c | 138 ++++++++++++++++++++++++
tools/objtool/objtool.c | 1 +
tools/objtool/weak.c | 5 +
11 files changed, 247 insertions(+), 3 deletions(-)
create mode 100644 tools/objtool/builtin-mcount.c
create mode 100644 tools/objtool/mcount.c
On PPC32 I get :
[ 0.000000] ftrace: No functions to be traced?
Without this series I get:
[ 0.000000] ftrace: allocating 22508 entries in 17 pages
[ 0.000000] ftrace: allocated 17 pages with 2 groups
ppc64_defconfig on QEMU:
[ 0.000000][ T0] ftrace: No functions to be traced?
Without your series:
[ 0.000000][ T0] ftrace: allocating 38750 entries in 15 pages
[ 0.000000][ T0] ftrace: allocated 15 pages with 4 groups
[ 0.000000][ T0] trace event string verifier disabled
On PPC32 I get :
[ 0.000000] ftrace: No functions to be traced?
Without this series I get:
[ 0.000000] ftrace: allocating 22508 entries in 17 pages
[ 0.000000] ftrace: allocated 17 pages with 2 groups
ppc64_defconfig on QEMU:
[ 0.000000][ T0] ftrace: No functions to be traced?
Without your series:
[ 0.000000][ T0] ftrace: allocating 38750 entries in 15 pages
[ 0.000000][ T0] ftrace: allocated 15 pages with 4 groups
[ 0.000000][ T0] trace event string verifier disabled
ppc64le_defconfig on QEMU:
[ 0.000000][ T0] ftrace: allocating 37236 entries in 14 pages
[ 0.000000][ T0] ftrace: allocated 14 pages with 3 groups
Without your series:
[ 0.000000][ T0] ftrace: allocating 37236 entries in 14 pages
[ 0.000000][ T0] ftrace: allocated 14 pages with 3 groups
So it seems it works only on Little Endian.
Works neither on PPC32 nor on PPC64 Big Endian
Christophe
From: Naveen N. Rao <hidden> Date: 2022-03-21 09:49:25
Christophe Leroy wrote:
Le 21/03/2022 à 09:19, Naveen N. Rao a écrit :
quoted
Christophe Leroy wrote:
We don't enable ftrace for vdso, so I suspect objtool run above will be
a no-op. This needs to be confirmed, of course.
I just checked without the series: recordmcount isn't run for VDSO, so
objtool shouldn't be run either when the series is applied.
Agree. I was only pointing out that it would be harmless, but it is good
to ensure objtool is skipped for files/directories where ftrace isn't
enabled. recordmcount keys off the presence of CC_FLAGS_FTRACE, and we
should do the same for 'objtool --mcount'.
- Naveen
Since you include <objtool/utils.h> in check.c, you can remove the
definition of sym_for_each_insn() macro from check.c as well.
I wonder if it would make sense to move all these helper functions to
utils.c and utils.h. Might be connected to what Josh wrote about his work
on objtool interface.
Regards
Miroslav
On PPC32 I get :
[ 0.000000] ftrace: No functions to be traced?
Without this series I get:
[ 0.000000] ftrace: allocating 22508 entries in 17 pages
[ 0.000000] ftrace: allocated 17 pages with 2 groups
With the changes below I managed to get a working ftrace on a PPC32 target.
Christophe
---------
From: Christophe Leroy <redacted>
Subject: [PATCH] powerpc/objtool: Set to big endian and 32 bits
Small ack to crossbuild a PPC32 kernel with a x86_64 host.
Signed-off-by: Christophe Leroy <redacted>
---
tools/objtool/arch/powerpc/decode.c | 3 ++-
tools/objtool/arch/powerpc/include/arch/endianness.h | 9 +++++++++
tools/objtool/elf.c | 4 ++--
tools/objtool/utils.c | 12 +++++++-----
4 files changed, 20 insertions(+), 8 deletions(-)
create mode 100644 tools/objtool/arch/powerpc/include/arch/endianness.h
Hi Peter, Hi Josh
Le 18/03/2022 à 13:26, Peter Zijlstra a écrit :
On Fri, Mar 18, 2022 at 04:21:40PM +0530, Sathvika Vasireddy wrote:
quoted
This patch adds powerpc specific functions required for
'objtool mcount' to work, and enables mcount for ppc.
I would love to see more objtool enablement for Power :-)
I'm also very happy someone started to look at it.
I thought it would be more difficult to get it work on powerpc.
Iml looking forward to being able to use it and implement INLINE STATIC
CALLs on PPC32 to start with.
I'm wondering what are the plans on your side and what we should wait
for and what we could start with.
I could do the same as done by Sathvika for static calls, in extenso get
it out of check.c into a standalone feature. On the other hand I
understood that Josh is also working at making the different features of
objtool independant, so should I wait for that ? Any idea of when it
comes out ?
Second point is the endianess and 32/64 selection, especially when
crossbuilding. There is already some stuff regarding endianess based on
bswap_if_needed() but that's based on constant selection at build time
and I couldn't find an easy way to set it conditionaly based on the
target being built.
Regarding 32/64 selection, there is almost nothing, it's based on using
type 'long' which means that at the time being the target and the build
platform must both be 32 bits or 64 bits.
For both cases (endianess and 32/64) I think the solution should
probably be to start with the fileformat of the object file being
reworked by objtool.
What are current works in progress on objtool ? Should I wait Josh's
changes before starting looking at all this ? Should I wait for anything
else ?
Christophe
On Sun, Mar 27, 2022 at 09:09:20AM +0000, Christophe Leroy wrote:
Second point is the endianess and 32/64 selection, especially when
crossbuilding. There is already some stuff regarding endianess based on
bswap_if_needed() but that's based on constant selection at build time
and I couldn't find an easy way to set it conditionaly based on the
target being built.
Regarding 32/64 selection, there is almost nothing, it's based on using
type 'long' which means that at the time being the target and the build
platform must both be 32 bits or 64 bits.
For both cases (endianess and 32/64) I think the solution should
probably be to start with the fileformat of the object file being
reworked by objtool.
Do we really need to detect the endianness/bitness at runtime? Objtool
is built with the kernel, why not just build-in the same target
assumptions as the kernel itself?
What are current works in progress on objtool ? Should I wait Josh's
changes before starting looking at all this ? Should I wait for anything
else ?
I'm not making any major changes to the code, just shuffling things
around to make the interface more modular. I hope to have something
soon (this week). Peter recently added a big feature (Intel IBT) which
is already in -next.
Contributions are welcome, with the understanding that you'll help
maintain it ;-)
Some years ago Kamalesh Babulal had a prototype of objtool for ppc64le
which did the full stack validation. I'm not sure what ever became of
that.
FWIW, there have been some objtool patches for arm64 stack validation,
but the arm64 maintainers have been hesitant to get on board with
objtool, as it brings a certain maintenance burden. Especially for the
full stack validation and ORC unwinder. But if you only want inline
static calls and/or mcount then it'd probably be much easier to
maintain.
--
Josh
From: Peter Zijlstra <peterz@infradead.org> Date: 2022-03-28 20:15:07
On Mon, Mar 28, 2022 at 12:59:20PM -0700, Josh Poimboeuf wrote:
I'm not making any major changes to the code, just shuffling things
around to make the interface more modular. I hope to have something
soon (this week). Peter recently added a big feature (Intel IBT) which
is already in -next.
Hit Linus' tree yesterday :-)
Some years ago Kamalesh Babulal had a prototype of objtool for ppc64le
which did the full stack validation. I'm not sure what ever became of
that.
I've also heard chatter about s390.
FWIW, there have been some objtool patches for arm64 stack validation,
but the arm64 maintainers have been hesitant to get on board with
objtool, as it brings a certain maintenance burden. Especially for the
full stack validation and ORC unwinder. But if you only want inline
static calls and/or mcount then it'd probably be much easier to
maintain.
IIRC the major stumbling block for arm64 is the whole jump-table thing.
Either they need to rely on compiler plugins to provide objtool that
data (yuck, since we support at least 2 different compilers), disable
jump-tables (yuck, for that limits code-gen just to please a tool) or
use DWARF (yuck, because build times).
There was a little talk about an impromptu 'abi' to communicate
jump-table details to objtool without going full on DWARF, but that
seems to have hit a dead end again.
From: Peter Zijlstra <peterz@infradead.org> Date: 2022-03-28 20:15:57
+arm64 people...
On Mon, Mar 28, 2022 at 10:14:38PM +0200, Peter Zijlstra wrote:
On Mon, Mar 28, 2022 at 12:59:20PM -0700, Josh Poimboeuf wrote:
quoted
I'm not making any major changes to the code, just shuffling things
around to make the interface more modular. I hope to have something
soon (this week). Peter recently added a big feature (Intel IBT) which
is already in -next.
Hit Linus' tree yesterday :-)
quoted
Some years ago Kamalesh Babulal had a prototype of objtool for ppc64le
which did the full stack validation. I'm not sure what ever became of
that.
I've also heard chatter about s390.
quoted
FWIW, there have been some objtool patches for arm64 stack validation,
but the arm64 maintainers have been hesitant to get on board with
objtool, as it brings a certain maintenance burden. Especially for the
full stack validation and ORC unwinder. But if you only want inline
static calls and/or mcount then it'd probably be much easier to
maintain.
IIRC the major stumbling block for arm64 is the whole jump-table thing.
Either they need to rely on compiler plugins to provide objtool that
data (yuck, since we support at least 2 different compilers), disable
jump-tables (yuck, for that limits code-gen just to please a tool) or
use DWARF (yuck, because build times).
There was a little talk about an impromptu 'abi' to communicate
jump-table details to objtool without going full on DWARF, but that
seems to have hit a dead end again.
On Mon, Mar 28, 2022 at 10:14:38PM +0200, Peter Zijlstra wrote:
quoted
FWIW, there have been some objtool patches for arm64 stack validation,
but the arm64 maintainers have been hesitant to get on board with
objtool, as it brings a certain maintenance burden. Especially for the
full stack validation and ORC unwinder. But if you only want inline
static calls and/or mcount then it'd probably be much easier to
maintain.
IIRC the major stumbling block for arm64 is the whole jump-table thing.
Either they need to rely on compiler plugins to provide objtool that
data (yuck, since we support at least 2 different compilers), disable
jump-tables (yuck, for that limits code-gen just to please a tool) or
use DWARF (yuck, because build times).
Well yeah, that was indeed the main technical issue but I seem to
remember some arm64 maintainers not really being sold on the value of
objtool regardless.
There was a little talk about an impromptu 'abi' to communicate
jump-table details to objtool without going full on DWARF, but that
seems to have hit a dead end again.
Probably my fault, not enough hours in the day...
--
Josh
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2022-03-29 12:01:52
Josh Poimboeuf [off-list ref] writes:
On Sun, Mar 27, 2022 at 09:09:20AM +0000, Christophe Leroy wrote:
quoted
Second point is the endianess and 32/64 selection, especially when
crossbuilding. There is already some stuff regarding endianess based on
bswap_if_needed() but that's based on constant selection at build time
and I couldn't find an easy way to set it conditionaly based on the
target being built.
Regarding 32/64 selection, there is almost nothing, it's based on using
type 'long' which means that at the time being the target and the build
platform must both be 32 bits or 64 bits.
For both cases (endianess and 32/64) I think the solution should
probably be to start with the fileformat of the object file being
reworked by objtool.
Do we really need to detect the endianness/bitness at runtime? Objtool
is built with the kernel, why not just build-in the same target
assumptions as the kernel itself?
I don't think we need runtime detection. But it will need to support
basically most combinations of objtool running as 32-bit/64-bit LE/BE
while the kernel it's analysing is 32-bit/64-bit LE/BE.
quoted
What are current works in progress on objtool ? Should I wait Josh's
changes before starting looking at all this ? Should I wait for anything
else ?
I'm not making any major changes to the code, just shuffling things
around to make the interface more modular. I hope to have something
soon (this week). Peter recently added a big feature (Intel IBT) which
is already in -next.
Contributions are welcome, with the understanding that you'll help
maintain it ;-)
Some years ago Kamalesh Babulal had a prototype of objtool for ppc64le
which did the full stack validation. I'm not sure what ever became of
that.
From memory he was starting to clean the patches up in late 2019, but I
guess that probably got derailed by COVID. AFAIK he never posted
anything. Maybe someone at IBM has a copy internally (Naveen?).
FWIW, there have been some objtool patches for arm64 stack validation,
but the arm64 maintainers have been hesitant to get on board with
objtool, as it brings a certain maintenance burden. Especially for the
full stack validation and ORC unwinder. But if you only want inline
static calls and/or mcount then it'd probably be much easier to
maintain.
I would like to have the stack validation, but I am also worried about
the maintenance burden.
I guess we start with mcount, which looks pretty minimal judging by this
series, and see how we go from there.
cheers
On Sun, Mar 27, 2022 at 09:09:20AM +0000, Christophe Leroy wrote:
quoted
Second point is the endianess and 32/64 selection, especially when
crossbuilding. There is already some stuff regarding endianess based on
bswap_if_needed() but that's based on constant selection at build time
and I couldn't find an easy way to set it conditionaly based on the
target being built.
Regarding 32/64 selection, there is almost nothing, it's based on using
type 'long' which means that at the time being the target and the build
platform must both be 32 bits or 64 bits.
For both cases (endianess and 32/64) I think the solution should
probably be to start with the fileformat of the object file being
reworked by objtool.
Do we really need to detect the endianness/bitness at runtime? Objtool
is built with the kernel, why not just build-in the same target
assumptions as the kernel itself?
I don't think we need runtime detection. But it will need to support
basically most combinations of objtool running as 32-bit/64-bit LE/BE
while the kernel it's analysing is 32-bit/64-bit LE/BE.
Exactly, the way it is done today with a constant in
objtool/endianness.h is too simple, we need to be able to select it
based on kernel's config. Is there a way to get the CONFIG_ macros from
the kernel ? If yes then we could use CONFIG_64BIT and
CONFIG_CPU_LITTLE_ENDIAN to select the correct options in objtool.
quoted
quoted
What are current works in progress on objtool ? Should I wait Josh's
changes before starting looking at all this ? Should I wait for anything
else ?
I'm not making any major changes to the code, just shuffling things
around to make the interface more modular. I hope to have something
soon (this week). Peter recently added a big feature (Intel IBT) which
is already in -next.
Contributions are welcome, with the understanding that you'll help
maintain it ;-)
Some years ago Kamalesh Babulal had a prototype of objtool for ppc64le
which did the full stack validation. I'm not sure what ever became of
that.
From memory he was starting to clean the patches up in late 2019, but I
guess that probably got derailed by COVID. AFAIK he never posted
anything. Maybe someone at IBM has a copy internally (Naveen?).
quoted
FWIW, there have been some objtool patches for arm64 stack validation,
but the arm64 maintainers have been hesitant to get on board with
objtool, as it brings a certain maintenance burden. Especially for the
full stack validation and ORC unwinder. But if you only want inline
static calls and/or mcount then it'd probably be much easier to
maintain.
I would like to have the stack validation, but I am also worried about
the maintenance burden.
I guess we start with mcount, which looks pretty minimal judging by this
series, and see how we go from there.
On Tue, Mar 29, 2022 at 05:32:18PM +0000, Christophe Leroy wrote:
Le 29/03/2022 à 14:01, Michael Ellerman a écrit :
quoted
Josh Poimboeuf [off-list ref] writes:
quoted
On Sun, Mar 27, 2022 at 09:09:20AM +0000, Christophe Leroy wrote:
quoted
Second point is the endianess and 32/64 selection, especially when
crossbuilding. There is already some stuff regarding endianess based on
bswap_if_needed() but that's based on constant selection at build time
and I couldn't find an easy way to set it conditionaly based on the
target being built.
Regarding 32/64 selection, there is almost nothing, it's based on using
type 'long' which means that at the time being the target and the build
platform must both be 32 bits or 64 bits.
For both cases (endianess and 32/64) I think the solution should
probably be to start with the fileformat of the object file being
reworked by objtool.
Do we really need to detect the endianness/bitness at runtime? Objtool
is built with the kernel, why not just build-in the same target
assumptions as the kernel itself?
I don't think we need runtime detection. But it will need to support
basically most combinations of objtool running as 32-bit/64-bit LE/BE
while the kernel it's analysing is 32-bit/64-bit LE/BE.
Exactly, the way it is done today with a constant in
objtool/endianness.h is too simple, we need to be able to select it
based on kernel's config. Is there a way to get the CONFIG_ macros from
the kernel ? If yes then we could use CONFIG_64BIT and
CONFIG_CPU_LITTLE_ENDIAN to select the correct options in objtool.
As of now, there's no good way to get CONFIG options from the kernel.
That's pretty much by design, since objtool is meant to be a standalone
tool. In fact there are people who've used objtool for other projects.
The objtool Makefile does at least have access to HOSTARCH/SRCARCH, but
I guess that doesn't help here. We could maybe export the endian/bit
details in env variables to the objtool build somehow.
But, I managed to forget that objtool can already be cross-compiled for
a x86-64 target, from a 32-bit x86 LE host or a 64-bit powerpc BE host.
There are some people out there doing x86 kernel builds on such systems
who reported bugs, which were since fixed. And the fixes were pretty
trivial, IIRC.
Libelf actually does a decent job of abstracting those details from
objtool. So, forget what I said, it might be ok to just detect
endian/bit (and possibly even arch) at runtime like you originally
suggested.
For example bswap_if_needed() could be reworked to be a runtime check.
--
Josh
From: Naveen N. Rao <hidden> Date: 2022-03-30 18:42:48
Christophe Leroy wrote:
Le 29/03/2022 à 14:01, Michael Ellerman a écrit :
quoted
Josh Poimboeuf [off-list ref] writes:
quoted
On Sun, Mar 27, 2022 at 09:09:20AM +0000, Christophe Leroy wrote:
quoted
What are current works in progress on objtool ? Should I wait Josh's
changes before starting looking at all this ? Should I wait for anything
else ?
I'm not making any major changes to the code, just shuffling things
around to make the interface more modular. I hope to have something
soon (this week). Peter recently added a big feature (Intel IBT) which
is already in -next.
Contributions are welcome, with the understanding that you'll help
maintain it ;-)
Some years ago Kamalesh Babulal had a prototype of objtool for ppc64le
which did the full stack validation. I'm not sure what ever became of
that.
From memory he was starting to clean the patches up in late 2019, but I
guess that probably got derailed by COVID. AFAIK he never posted
anything. Maybe someone at IBM has a copy internally (Naveen?).
Kamalesh had a WIP series to enable stack validation on powerpc. From
what I recall, he was waiting on and/or working with the arm64 folks
around some of the common changes needed in objtool.
quoted
quoted
FWIW, there have been some objtool patches for arm64 stack validation,
but the arm64 maintainers have been hesitant to get on board with
objtool, as it brings a certain maintenance burden. Especially for the
full stack validation and ORC unwinder. But if you only want inline
static calls and/or mcount then it'd probably be much easier to
maintain.
I would like to have the stack validation, but I am also worried about
the maintenance burden.
I guess we start with mcount, which looks pretty minimal judging by this
series, and see how we go from there.
I'm not sure mcount is really needed as we have recordmcount, but at
least it is an easy one to start with and as we have recordmount we can
easily compare the results and check it works as expected.
Hi Josh,
Le 28/03/2022 à 21:59, Josh Poimboeuf a écrit :
On Sun, Mar 27, 2022 at 09:09:20AM +0000, Christophe Leroy wrote:
quoted
What are current works in progress on objtool ? Should I wait Josh's
changes before starting looking at all this ? Should I wait for anything
else ?
I'm not making any major changes to the code, just shuffling things
around to make the interface more modular. I hope to have something
soon (this week). Peter recently added a big feature (Intel IBT) which
is already in -next.
Were you able to send out something ?
Thanks
Christophe
On Thu, May 12, 2022 at 02:52:40PM +0000, Christophe Leroy wrote:
Hi Josh,
Le 28/03/2022 à 21:59, Josh Poimboeuf a écrit :
quoted
On Sun, Mar 27, 2022 at 09:09:20AM +0000, Christophe Leroy wrote:
quoted
What are current works in progress on objtool ? Should I wait Josh's
changes before starting looking at all this ? Should I wait for anything
else ?
I'm not making any major changes to the code, just shuffling things
around to make the interface more modular. I hope to have something
soon (this week). Peter recently added a big feature (Intel IBT) which
is already in -next.
Were you able to send out something ?
Yes, the objtool rewrite is now in tip/objtool/core and linux-next.
--
Josh
On Thu, May 12, 2022 at 02:52:40PM +0000, Christophe Leroy wrote:
quoted
Hi Josh,
Le 28/03/2022 à 21:59, Josh Poimboeuf a écrit :
quoted
On Sun, Mar 27, 2022 at 09:09:20AM +0000, Christophe Leroy wrote:
quoted
What are current works in progress on objtool ? Should I wait Josh's
changes before starting looking at all this ? Should I wait for anything
else ?
I'm not making any major changes to the code, just shuffling things
around to make the interface more modular. I hope to have something
soon (this week). Peter recently added a big feature (Intel IBT) which
is already in -next.
Were you able to send out something ?
Yes, the objtool rewrite is now in tip/objtool/core and linux-next.
Nice.
I gave it a try this morning, I selected HAVE_OBJTOOL and
HAVE_OBJTOOL_MCOUNT from arch/powerpc/Kconfig
Seems like there are still some x86 arch specific stuff in common common
code and I get the following errors.
Also, is it normal to get those functions built allthough I have not
selected HAVE_STACK_VALIDATION ?
CC /home/chleroy/linux-powerpc/tools/objtool/check.o
check.c: In function 'has_valid_stack_frame':
check.c:2369:30: error: 'CFI_BP' undeclared (first use in this
function); did you mean 'CFI_SP'?
2369 | if (cfi->cfa.base == CFI_BP &&
| ^~~~~~
| CFI_SP
check.c:2369:30: note: each undeclared identifier is reported only once
for each function it appears in
check.c:2371:44: error: 'CFI_RA' undeclared (first use in this
function); did you mean 'CFI_R3'?
2371 | check_reg_frame_pos(&cfi->regs[CFI_RA],
-cfi->cfa.offset + 8))
| ^~~~~~
| CFI_R3
check.c: In function 'update_cfi_state':
check.c:2499:70: error: 'CFI_BP' undeclared (first use in this
function); did you mean 'CFI_SP'?
2499 | if (op->src.reg == CFI_SP &&
op->dest.reg == CFI_BP &&
|
^~~~~~
|
CFI_SP
make[3]: *** [/home/chleroy/linux-powerpc/tools/build/Makefile.build:97:
/home/chleroy/linux-powerpc/tools/objtool/check.o] Error 1
make[2]: *** [Makefile:54:
/home/chleroy/linux-powerpc/tools/objtool/objtool-in.o] Error 2
make[1]: *** [Makefile:69: objtool] Error 2
make: *** [Makefile:1337: tools/objtool] Error 2
What would be the best approach to fix that ?
Thanks
Christophe
From: Peter Zijlstra <peterz@infradead.org> Date: 2022-05-21 10:57:36
On Sat, May 21, 2022 at 09:38:35AM +0000, Christophe Leroy wrote:
I gave it a try this morning, I selected HAVE_OBJTOOL and
HAVE_OBJTOOL_MCOUNT from arch/powerpc/Kconfig
Seems like there are still some x86 arch specific stuff in common common
code and I get the following errors.
I'm assuming there's a metric ton of x86 specific stuff in there.
That'll take a while to clean out.
Mostly Josh's rewrite was centered around splitting out the runtime
options, but objtool is still always build with all options included,
even the ones you're not using for your arch, which is what's triggering
the problems you see here, I suppose...
Also, is it normal to get those functions built allthough I have not
selected HAVE_STACK_VALIDATION ?
CC /home/chleroy/linux-powerpc/tools/objtool/check.o
check.c: In function 'has_valid_stack_frame':
check.c:2369:30: error: 'CFI_BP' undeclared (first use in this
function); did you mean 'CFI_SP'?
2369 | if (cfi->cfa.base == CFI_BP &&
| ^~~~~~
| CFI_SP
check.c:2369:30: note: each undeclared identifier is reported only once
for each function it appears in
check.c:2371:44: error: 'CFI_RA' undeclared (first use in this
function); did you mean 'CFI_R3'?
2371 | check_reg_frame_pos(&cfi->regs[CFI_RA],
-cfi->cfa.offset + 8))
| ^~~~~~
| CFI_R3
check.c: In function 'update_cfi_state':
check.c:2499:70: error: 'CFI_BP' undeclared (first use in this
function); did you mean 'CFI_SP'?
2499 | if (op->src.reg == CFI_SP &&
op->dest.reg == CFI_BP &&
|
^~~~~~
|
CFI_SP
make[3]: *** [/home/chleroy/linux-powerpc/tools/build/Makefile.build:97:
/home/chleroy/linux-powerpc/tools/objtool/check.o] Error 1
make[2]: *** [Makefile:54:
/home/chleroy/linux-powerpc/tools/objtool/objtool-in.o] Error 2
make[1]: *** [Makefile:69: objtool] Error 2
make: *** [Makefile:1337: tools/objtool] Error 2
What would be the best approach to fix that ?
Define CFI_BP to your frame register (r2, afaict) I suppose. If you're
only using OBJTOOL_MCOUNT this code will never run, so all you have to
ensure is that it compiles, not that it makes sense (-:
The very long and complicated way would be to propagate the various
CONFIG_HAVE_* build time things to the objtool build and librally
sprinkle a lot of #ifdef around.
From: Naveen N. Rao <hidden> Date: 2022-05-23 05:40:58
Peter Zijlstra wrote:
On Sat, May 21, 2022 at 09:38:35AM +0000, Christophe Leroy wrote:
quoted
I gave it a try this morning, I selected HAVE_OBJTOOL and
HAVE_OBJTOOL_MCOUNT from arch/powerpc/Kconfig
Seems like there are still some x86 arch specific stuff in common common
code and I get the following errors.
I'm assuming there's a metric ton of x86 specific stuff in there.
That'll take a while to clean out.
Mostly Josh's rewrite was centered around splitting out the runtime
options, but objtool is still always build with all options included,
even the ones you're not using for your arch, which is what's triggering
the problems you see here, I suppose...
quoted
Also, is it normal to get those functions built allthough I have not
selected HAVE_STACK_VALIDATION ?
CC /home/chleroy/linux-powerpc/tools/objtool/check.o
check.c: In function 'has_valid_stack_frame':
check.c:2369:30: error: 'CFI_BP' undeclared (first use in this
function); did you mean 'CFI_SP'?
2369 | if (cfi->cfa.base == CFI_BP &&
| ^~~~~~
| CFI_SP
check.c:2369:30: note: each undeclared identifier is reported only once
for each function it appears in
check.c:2371:44: error: 'CFI_RA' undeclared (first use in this
function); did you mean 'CFI_R3'?
2371 | check_reg_frame_pos(&cfi->regs[CFI_RA],
-cfi->cfa.offset + 8))
| ^~~~~~
| CFI_R3
check.c: In function 'update_cfi_state':
check.c:2499:70: error: 'CFI_BP' undeclared (first use in this
function); did you mean 'CFI_SP'?
2499 | if (op->src.reg == CFI_SP &&
op->dest.reg == CFI_BP &&
|
^~~~~~
|
CFI_SP
make[3]: *** [/home/chleroy/linux-powerpc/tools/build/Makefile.build:97:
/home/chleroy/linux-powerpc/tools/objtool/check.o] Error 1
make[2]: *** [Makefile:54:
/home/chleroy/linux-powerpc/tools/objtool/objtool-in.o] Error 2
make[1]: *** [Makefile:69: objtool] Error 2
make: *** [Makefile:1337: tools/objtool] Error 2
What would be the best approach to fix that ?
Define CFI_BP to your frame register (r2, afaict) I suppose. If you're
only using OBJTOOL_MCOUNT this code will never run, so all you have to
ensure is that it compiles, not that it makes sense (-:
Sathvika has been looking into this.
The very long and complicated way would be to propagate the various
CONFIG_HAVE_* build time things to the objtool build and librally
sprinkle a lot of #ifdef around.
I think there were just a couple of unrelated checks/warnings that were
causing problems on powerpc. So, we likely won't need too many #ifdefs,
at least for mcount purposes.
Sathvika,
Can you post what you have?
- Naveen