There are some "unreachable instruction" objtool warnings when compling
with Clang on LoongArch, this is because the "break" instruction is set
as dead end due to its type is INSN_BUG in decode_instructions() at the
beginning, and it does not set insn->dead_end of the "break" instruction
as false after checking ".rela.discard.reachable" in add_dead_ends(), so
the next instruction of "break" is marked as unreachable.
Actually, it can find the reachable instruction after parsing the section
".rela.discard.reachable", in some cases, the "break" instruction may not
be the first previous instruction with scheduling by Machine Instruction
Scheduler of LLVM, it should find more times and then set insn->dead_end
of the "break" instruction as false.
This is preparation for later patch on LoongArch, there is no effect for
the other archs with this patch.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
tools/objtool/check.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 9601235e908d..191950551352 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -22,6 +22,10 @@
#include <linux/static_call_types.h>
#include <linux/string.h>
+#ifndef EM_LOONGARCH
+#define EM_LOONGARCH 258
+#endif
+
struct alternative {
struct alternative *next;
struct instruction *insn;
@@ -711,6 +715,18 @@ static int add_dead_ends(struct objtool_file *file)
}
insn->dead_end = false;
+
+ /* Handle the special cases compiled with Clang on LoongArch */
+ if (file->elf->ehdr.e_machine == EM_LOONGARCH &&
+ reloc->sym->type == STT_SECTION) {
+ while (insn && insn_func(insn)) {
+ insn = prev_insn_same_sym(file, insn);
+ if (insn && insn->dead_end) {
+ insn->dead_end = false;
+ break;
+ }
+ }
+ }
}
return 0;
--
2.42.0On Fri, Nov 22, 2024 at 12:49:57PM +0800, Tiezhu Yang wrote:
> There are some "unreachable instruction" objtool warnings when compling
> with Clang on LoongArch, this is because the "break" instruction is set
> as dead end due to its type is INSN_BUG in decode_instructions() at the
> beginning, and it does not set insn->dead_end of the "break" instruction
> as false after checking ".rela.discard.reachable" in add_dead_ends(), so
> the next instruction of "break" is marked as unreachable.
>
> Actually, it can find the reachable instruction after parsing the section
> ".rela.discard.reachable", in some cases, the "break" instruction may not
> be the first previous instruction with scheduling by Machine Instruction
> Scheduler of LLVM, it should find more times and then set insn->dead_end
> of the "break" instruction as false.
>
> This is preparation for later patch on LoongArch, there is no effect for
> the other archs with this patch.
>
> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
I'm having trouble understanding this commit log, is the problem that
the compiler is sometimes inserting code between 'break' and the
unreachable() inline asm?
If so, this sounds like a problem that was already solved for x86 with:
bfb1a7c91fb7 ("x86/bug: Merge annotate_reachable() into _BUG_FLAGS() asm")
Can you check if that fixes it?
--
Josh
On 11/26/2024 02:45 PM, Josh Poimboeuf wrote:
> On Fri, Nov 22, 2024 at 12:49:57PM +0800, Tiezhu Yang wrote:
>> There are some "unreachable instruction" objtool warnings when compling
>> with Clang on LoongArch, this is because the "break" instruction is set
>> as dead end due to its type is INSN_BUG in decode_instructions() at the
>> beginning, and it does not set insn->dead_end of the "break" instruction
>> as false after checking ".rela.discard.reachable" in add_dead_ends(), so
>> the next instruction of "break" is marked as unreachable.
>>
>> Actually, it can find the reachable instruction after parsing the section
>> ".rela.discard.reachable", in some cases, the "break" instruction may not
>> be the first previous instruction with scheduling by Machine Instruction
>> Scheduler of LLVM, it should find more times and then set insn->dead_end
>> of the "break" instruction as false.
>>
>> This is preparation for later patch on LoongArch, there is no effect for
>> the other archs with this patch.
>>
>> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
>
> I'm having trouble understanding this commit log, is the problem that
> the compiler is sometimes inserting code between 'break' and the
> unreachable() inline asm?
>
> If so, this sounds like a problem that was already solved for x86 with:
>
> bfb1a7c91fb7 ("x86/bug: Merge annotate_reachable() into _BUG_FLAGS() asm")
>
> Can you check if that fixes it?
I will try, thank you.
On Tue, Nov 26, 2024 at 06:42:15PM +0800, Tiezhu Yang wrote:
> On 11/26/2024 02:45 PM, Josh Poimboeuf wrote:
> > On Fri, Nov 22, 2024 at 12:49:57PM +0800, Tiezhu Yang wrote:
> > > There are some "unreachable instruction" objtool warnings when compling
> > > with Clang on LoongArch, this is because the "break" instruction is set
> > > as dead end due to its type is INSN_BUG in decode_instructions() at the
> > > beginning, and it does not set insn->dead_end of the "break" instruction
> > > as false after checking ".rela.discard.reachable" in add_dead_ends(), so
> > > the next instruction of "break" is marked as unreachable.
> > >
> > > Actually, it can find the reachable instruction after parsing the section
> > > ".rela.discard.reachable", in some cases, the "break" instruction may not
> > > be the first previous instruction with scheduling by Machine Instruction
> > > Scheduler of LLVM, it should find more times and then set insn->dead_end
> > > of the "break" instruction as false.
> > >
> > > This is preparation for later patch on LoongArch, there is no effect for
> > > the other archs with this patch.
> > >
> > > Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> >
> > I'm having trouble understanding this commit log, is the problem that
> > the compiler is sometimes inserting code between 'break' and the
> > unreachable() inline asm?
> >
> > If so, this sounds like a problem that was already solved for x86 with:
> >
> > bfb1a7c91fb7 ("x86/bug: Merge annotate_reachable() into _BUG_FLAGS() asm")
> >
> > Can you check if that fixes it?
>
> I will try, thank you.
>
I was poking at the reachable annotations and ended up with this:
--- a/arch/loongarch/include/asm/bug.h
+++ b/arch/loongarch/include/asm/bug.h
@@ -4,6 +4,7 @@
#include <asm/break.h>
#include <linux/stringify.h>
+#include <linux/objtool.h>
#ifndef CONFIG_DEBUG_BUGVERBOSE
#define _BUGVERBOSE_LOCATION(file, line)
@@ -37,21 +38,21 @@
#define ASM_BUG() ASM_BUG_FLAGS(0)
-#define __BUG_FLAGS(flags) \
- asm_inline volatile (__stringify(ASM_BUG_FLAGS(flags)));
+#define __BUG_FLAGS(flags, extra) \
+ asm_inline volatile (__stringify(ASM_BUG_FLAGS(flags)) \
+ extra);
#define __WARN_FLAGS(flags) \
do { \
instrumentation_begin(); \
- __BUG_FLAGS(BUGFLAG_WARNING|(flags)); \
- annotate_reachable(); \
+ __BUG_FLAGS(BUGFLAG_WARNING|(flags), ASM_REACHABLE); \
instrumentation_end(); \
} while (0)
#define BUG() \
do { \
instrumentation_begin(); \
- __BUG_FLAGS(0); \
+ __BUG_FLAGS(0, ""); \
unreachable(); \
} while (0)
> I was poking at the reachable annotations and ended up with this:
Also see here:
https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?h=objtool/core
Once the robots agree it all compiles, I'll post.
> --- a/arch/loongarch/include/asm/bug.h
> +++ b/arch/loongarch/include/asm/bug.h
> @@ -4,6 +4,7 @@
>
> #include <asm/break.h>
> #include <linux/stringify.h>
> +#include <linux/objtool.h>
>
> #ifndef CONFIG_DEBUG_BUGVERBOSE
> #define _BUGVERBOSE_LOCATION(file, line)
> @@ -37,21 +38,21 @@
>
> #define ASM_BUG() ASM_BUG_FLAGS(0)
>
> -#define __BUG_FLAGS(flags) \
> - asm_inline volatile (__stringify(ASM_BUG_FLAGS(flags)));
> +#define __BUG_FLAGS(flags, extra) \
> + asm_inline volatile (__stringify(ASM_BUG_FLAGS(flags)) \
> + extra);
>
> #define __WARN_FLAGS(flags) \
> do { \
> instrumentation_begin(); \
> - __BUG_FLAGS(BUGFLAG_WARNING|(flags)); \
> - annotate_reachable(); \
> + __BUG_FLAGS(BUGFLAG_WARNING|(flags), ASM_REACHABLE); \
> instrumentation_end(); \
> } while (0)
>
> #define BUG() \
> do { \
> instrumentation_begin(); \
> - __BUG_FLAGS(0); \
> + __BUG_FLAGS(0, ""); \
> unreachable(); \
> } while (0)
>
On 11/26/2024 11:22 PM, Peter Zijlstra wrote:
>
>> I was poking at the reachable annotations and ended up with this:
>
> Also see here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?h=objtool/core
>
> Once the robots agree it all compiles, I'll post.
There are many changes of tools/objtool/check.c in your tree,
I assume the patches in objtool/core tree is to target 6.13-rc1,
it failed when compiling on LoongArch:
arch/loongarch/include/asm/bug.h:49:60: error: expected ‘:’ or ‘)’
before ‘;’ token
{standard input}:682: Error: no match insn: break 1.pushsection
.discard.annotate_insn,"M",@progbits,8
I think it needs to do the following changes, please squash them to
your original commit if possible, thanks.
diff --git a/arch/loongarch/include/asm/bug.h
b/arch/loongarch/include/asm/bug.h
index dfb0cfccf36e..e5d888cb738f 100644
--- a/arch/loongarch/include/asm/bug.h
+++ b/arch/loongarch/include/asm/bug.h
@@ -40,13 +40,14 @@
#define __BUG_FLAGS(flags, extra) \
asm_inline volatile (__stringify(ASM_BUG_FLAGS(flags)) \
+ "\n" \
extra);
#define __WARN_FLAGS(flags) \
do { \
instrumentation_begin(); \
__BUG_FLAGS(BUGFLAG_WARNING|(flags), \
- __ANNOTATE_REACHABLE(__ASM_BREF(10001)); \
+ __ANNOTATE_REACHABLE(__ASM_BREF(10001))); \
instrumentation_end(); \
} while (0)
By the way, there are a lot of new objtool warnings
Unkonwn annotation type: 8
on LoongArch when compiling the code of your tree.
Thanks,
Tiezhu
© 2016 - 2026 Red Hat, Inc.