From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Sathvika Vasireddy <sv@linux.vnet.ibm.com>,
Sathvika Vasireddy <sv@linux.ibm.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Cc: "jpoimboe@redhat.com" <jpoimboe@redhat.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"aik@ozlabs.ru" <aik@ozlabs.ru>,
"mpe@ellerman.id.au" <mpe@ellerman.id.au>,
"mingo@redhat.com" <mingo@redhat.com>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
"naveen.n.rao@linux.vnet.ibm.com"
<naveen.n.rao@linux.vnet.ibm.com>,
"mbenes@suse.cz" <mbenes@suse.cz>,
"benh@kernel.crashing.org" <benh@kernel.crashing.org>,
"paulus@samba.org" <paulus@samba.org>,
Chen Zhongjin <chenzhongjin@huawei.com>,
Marc Zyngier <maz@kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH v3 11/12] powerpc: Remove unreachable() from WARN_ON()
Date: Wed, 29 Jun 2022 18:30:23 +0000 [thread overview]
Message-ID: <cce19b1c-449a-f306-533a-9edc855049aa@csgroup.eu> (raw)
In-Reply-To: <92eae2ef-f9b6-019a-5a8e-728cdd9bbbc0@linux.vnet.ibm.com>
Hi Sathvika,
Adding ARM people as they seem to face the same kind of problem (see
https://patchwork.kernel.org/project/linux-kbuild/patch/20220623014917.199563-33-chenzhongjin@huawei.com/)
Le 27/06/2022 à 17:35, Sathvika Vasireddy a écrit :
>
> On 25/06/22 12:16, Christophe Leroy wrote:
>>
>> Le 24/06/2022 à 20:32, Sathvika Vasireddy a écrit :
>>> objtool is throwing *unannotated intra-function call*
>>> warnings with a few instructions that are marked
>>> unreachable. Remove unreachable() from WARN_ON()
>>> to fix these warnings, as the codegen remains same
>>> with and without unreachable() in WARN_ON().
>> Did you try the two exemples described in commit 1e688dd2a3d6
>> ("powerpc/bug: Provide better flexibility to WARN_ON/__WARN_FLAGS() with
>> asm goto") ?
>>
>> Without your patch:
>>
>> 00000640 <test>:
>> 640: 81 23 00 84 lwz r9,132(r3)
>> 644: 71 29 40 00 andi. r9,r9,16384
>> 648: 40 82 00 0c bne 654 <test+0x14>
>> 64c: 80 63 00 0c lwz r3,12(r3)
>> 650: 4e 80 00 20 blr
>> 654: 0f e0 00 00 twui r0,0
>>
>> 00000658 <test9w>:
>> 658: 2c 04 00 00 cmpwi r4,0
>> 65c: 41 82 00 0c beq 668 <test9w+0x10>
>> 660: 7c 63 23 96 divwu r3,r3,r4
>> 664: 4e 80 00 20 blr
>> 668: 0f e0 00 00 twui r0,0
>> 66c: 38 60 00 00 li r3,0
>> 670: 4e 80 00 20 blr
>>
>>
>> With your patch:
>>
>> 00000640 <test>:
>> 640: 81 23 00 84 lwz r9,132(r3)
>> 644: 71 29 40 00 andi. r9,r9,16384
>> 648: 40 82 00 0c bne 654 <test+0x14>
>> 64c: 80 63 00 0c lwz r3,12(r3)
>> 650: 4e 80 00 20 blr
>> 654: 0f e0 00 00 twui r0,0
>> 658: 4b ff ff f4 b 64c <test+0xc> <==
>>
>> 0000065c <test9w>:
>> 65c: 2c 04 00 00 cmpwi r4,0
>> 660: 41 82 00 0c beq 66c <test9w+0x10>
>> 664: 7c 63 23 96 divwu r3,r3,r4
>> 668: 4e 80 00 20 blr
>> 66c: 0f e0 00 00 twui r0,0
>> 670: 38 60 00 00 li r3,0 <==
>> 674: 4e 80 00 20 blr <==
>> 678: 38 60 00 00 li r3,0
>> 67c: 4e 80 00 20 blr
>>
> The builtin variant of unreachable (__builtin_unreachable()) works.
>
> How about using that instead of unreachable() ?
>
>
In fact the problem comes from the macro annotate_unreachable() which is
called by unreachable() before calling __build_unreachable().
Seems like this macro adds (after the unconditional trap twui) a call to
an empty function whose address is listed in section .discard.unreachable
1c78: 00 00 e0 0f twui r0,0
1c7c: 55 e7 ff 4b bl 3d0
<qdisc_root_sleeping_lock.part.0>
RELOCATION RECORDS FOR [.discard.unreachable]:
OFFSET TYPE VALUE
0000000000000000 R_PPC64_REL32 .text+0x00000000000003d0
The problem is that that function has size 0:
00000000000003d0 l F .text 0000000000000000
qdisc_root_sleeping_lock.part.0
And objtool is not prepared for a function with size 0.
The following changes to objtool seem to fix the problem, most warning
are gone with that change.
diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 63218f5799c2..37c0a268b7ea 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -77,6 +77,8 @@ static int symbol_by_offset(const void *key, const
struct rb_node *node)
if (*o < s->offset)
return -1;
+ if (*o == s->offset && !s->len)
+ return 0;
if (*o >= s->offset + s->len)
return 1;
@@ -400,7 +402,7 @@ static void elf_add_symbol(struct elf *elf, struct
symbol *sym)
* Don't store empty STT_NOTYPE symbols in the rbtree. They
* can exist within a function, confusing the sorting.
*/
- if (!sym->len)
+ if (sym->type == STT_NOTYPE && !sym->len)
rb_erase(&sym->node, &sym->sec->symbol_tree);
}
---
I also had objtool running for ever on
arch/powerpc/sysdev/xics/icp-hv.o, which I fixed with the below hack:
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 51b6dcec8d6a..ef2303ad6381 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -529,7 +529,7 @@ static struct instruction *find_last_insn(struct
objtool_file *file,
unsigned int offset;
unsigned int end = (sec->sh.sh_size > 10) ? sec->sh.sh_size - 10 : 0;
- for (offset = sec->sh.sh_size - 1; offset >= end && !insn; offset--)
+ for (offset = sec->sh.sh_size - 1; offset && offset >= end && !insn;
offset--)
insn = find_insn(file, sec, offset);
return insn;
---
Now I only have the following two warnings:
arch/powerpc/sysdev/xics/icp-hv.o: warning: objtool: can't find
unreachable insn at .text.unlikely+0x0
drivers/crypto/vmx/aesp8-ppc.o: warning: objtool:
aes_p8_set_encrypt_key+0x44: unannotated intra-function call
The first one is linked to the infinite loop I hacked. So I now have to
understand what the problem really is.
The second one is an assembly file aesp8-ppc.S which lacks the changes
you did in other assembly files in patch 12.
Christophe
WARNING: multiple messages have this Message-ID (diff)
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Sathvika Vasireddy <sv@linux.vnet.ibm.com>,
Sathvika Vasireddy <sv@linux.ibm.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Cc: Marc Zyngier <maz@kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
"aik@ozlabs.ru" <aik@ozlabs.ru>,
"mingo@redhat.com" <mingo@redhat.com>,
"paulus@samba.org" <paulus@samba.org>,
"jpoimboe@redhat.com" <jpoimboe@redhat.com>,
"naveen.n.rao@linux.vnet.ibm.com"
<naveen.n.rao@linux.vnet.ibm.com>,
"mbenes@suse.cz" <mbenes@suse.cz>,
Chen Zhongjin <chenzhongjin@huawei.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH v3 11/12] powerpc: Remove unreachable() from WARN_ON()
Date: Wed, 29 Jun 2022 18:30:23 +0000 [thread overview]
Message-ID: <cce19b1c-449a-f306-533a-9edc855049aa@csgroup.eu> (raw)
In-Reply-To: <92eae2ef-f9b6-019a-5a8e-728cdd9bbbc0@linux.vnet.ibm.com>
Hi Sathvika,
Adding ARM people as they seem to face the same kind of problem (see
https://patchwork.kernel.org/project/linux-kbuild/patch/20220623014917.199563-33-chenzhongjin@huawei.com/)
Le 27/06/2022 à 17:35, Sathvika Vasireddy a écrit :
>
> On 25/06/22 12:16, Christophe Leroy wrote:
>>
>> Le 24/06/2022 à 20:32, Sathvika Vasireddy a écrit :
>>> objtool is throwing *unannotated intra-function call*
>>> warnings with a few instructions that are marked
>>> unreachable. Remove unreachable() from WARN_ON()
>>> to fix these warnings, as the codegen remains same
>>> with and without unreachable() in WARN_ON().
>> Did you try the two exemples described in commit 1e688dd2a3d6
>> ("powerpc/bug: Provide better flexibility to WARN_ON/__WARN_FLAGS() with
>> asm goto") ?
>>
>> Without your patch:
>>
>> 00000640 <test>:
>> 640: 81 23 00 84 lwz r9,132(r3)
>> 644: 71 29 40 00 andi. r9,r9,16384
>> 648: 40 82 00 0c bne 654 <test+0x14>
>> 64c: 80 63 00 0c lwz r3,12(r3)
>> 650: 4e 80 00 20 blr
>> 654: 0f e0 00 00 twui r0,0
>>
>> 00000658 <test9w>:
>> 658: 2c 04 00 00 cmpwi r4,0
>> 65c: 41 82 00 0c beq 668 <test9w+0x10>
>> 660: 7c 63 23 96 divwu r3,r3,r4
>> 664: 4e 80 00 20 blr
>> 668: 0f e0 00 00 twui r0,0
>> 66c: 38 60 00 00 li r3,0
>> 670: 4e 80 00 20 blr
>>
>>
>> With your patch:
>>
>> 00000640 <test>:
>> 640: 81 23 00 84 lwz r9,132(r3)
>> 644: 71 29 40 00 andi. r9,r9,16384
>> 648: 40 82 00 0c bne 654 <test+0x14>
>> 64c: 80 63 00 0c lwz r3,12(r3)
>> 650: 4e 80 00 20 blr
>> 654: 0f e0 00 00 twui r0,0
>> 658: 4b ff ff f4 b 64c <test+0xc> <==
>>
>> 0000065c <test9w>:
>> 65c: 2c 04 00 00 cmpwi r4,0
>> 660: 41 82 00 0c beq 66c <test9w+0x10>
>> 664: 7c 63 23 96 divwu r3,r3,r4
>> 668: 4e 80 00 20 blr
>> 66c: 0f e0 00 00 twui r0,0
>> 670: 38 60 00 00 li r3,0 <==
>> 674: 4e 80 00 20 blr <==
>> 678: 38 60 00 00 li r3,0
>> 67c: 4e 80 00 20 blr
>>
> The builtin variant of unreachable (__builtin_unreachable()) works.
>
> How about using that instead of unreachable() ?
>
>
In fact the problem comes from the macro annotate_unreachable() which is
called by unreachable() before calling __build_unreachable().
Seems like this macro adds (after the unconditional trap twui) a call to
an empty function whose address is listed in section .discard.unreachable
1c78: 00 00 e0 0f twui r0,0
1c7c: 55 e7 ff 4b bl 3d0
<qdisc_root_sleeping_lock.part.0>
RELOCATION RECORDS FOR [.discard.unreachable]:
OFFSET TYPE VALUE
0000000000000000 R_PPC64_REL32 .text+0x00000000000003d0
The problem is that that function has size 0:
00000000000003d0 l F .text 0000000000000000
qdisc_root_sleeping_lock.part.0
And objtool is not prepared for a function with size 0.
The following changes to objtool seem to fix the problem, most warning
are gone with that change.
diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 63218f5799c2..37c0a268b7ea 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -77,6 +77,8 @@ static int symbol_by_offset(const void *key, const
struct rb_node *node)
if (*o < s->offset)
return -1;
+ if (*o == s->offset && !s->len)
+ return 0;
if (*o >= s->offset + s->len)
return 1;
@@ -400,7 +402,7 @@ static void elf_add_symbol(struct elf *elf, struct
symbol *sym)
* Don't store empty STT_NOTYPE symbols in the rbtree. They
* can exist within a function, confusing the sorting.
*/
- if (!sym->len)
+ if (sym->type == STT_NOTYPE && !sym->len)
rb_erase(&sym->node, &sym->sec->symbol_tree);
}
---
I also had objtool running for ever on
arch/powerpc/sysdev/xics/icp-hv.o, which I fixed with the below hack:
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 51b6dcec8d6a..ef2303ad6381 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -529,7 +529,7 @@ static struct instruction *find_last_insn(struct
objtool_file *file,
unsigned int offset;
unsigned int end = (sec->sh.sh_size > 10) ? sec->sh.sh_size - 10 : 0;
- for (offset = sec->sh.sh_size - 1; offset >= end && !insn; offset--)
+ for (offset = sec->sh.sh_size - 1; offset && offset >= end && !insn;
offset--)
insn = find_insn(file, sec, offset);
return insn;
---
Now I only have the following two warnings:
arch/powerpc/sysdev/xics/icp-hv.o: warning: objtool: can't find
unreachable insn at .text.unlikely+0x0
drivers/crypto/vmx/aesp8-ppc.o: warning: objtool:
aes_p8_set_encrypt_key+0x44: unannotated intra-function call
The first one is linked to the infinite loop I hacked. So I now have to
understand what the problem really is.
The second one is an assembly file aesp8-ppc.S which lacks the changes
you did in other assembly files in patch 12.
Christophe
WARNING: multiple messages have this Message-ID (diff)
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Sathvika Vasireddy <sv@linux.vnet.ibm.com>,
Sathvika Vasireddy <sv@linux.ibm.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Cc: "jpoimboe@redhat.com" <jpoimboe@redhat.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"aik@ozlabs.ru" <aik@ozlabs.ru>,
"mpe@ellerman.id.au" <mpe@ellerman.id.au>,
"mingo@redhat.com" <mingo@redhat.com>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
"naveen.n.rao@linux.vnet.ibm.com"
<naveen.n.rao@linux.vnet.ibm.com>,
"mbenes@suse.cz" <mbenes@suse.cz>,
"benh@kernel.crashing.org" <benh@kernel.crashing.org>,
"paulus@samba.org" <paulus@samba.org>,
Chen Zhongjin <chenzhongjin@huawei.com>,
Marc Zyngier <maz@kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH v3 11/12] powerpc: Remove unreachable() from WARN_ON()
Date: Wed, 29 Jun 2022 18:30:23 +0000 [thread overview]
Message-ID: <cce19b1c-449a-f306-533a-9edc855049aa@csgroup.eu> (raw)
In-Reply-To: <92eae2ef-f9b6-019a-5a8e-728cdd9bbbc0@linux.vnet.ibm.com>
Hi Sathvika,
Adding ARM people as they seem to face the same kind of problem (see
https://patchwork.kernel.org/project/linux-kbuild/patch/20220623014917.199563-33-chenzhongjin@huawei.com/)
Le 27/06/2022 à 17:35, Sathvika Vasireddy a écrit :
>
> On 25/06/22 12:16, Christophe Leroy wrote:
>>
>> Le 24/06/2022 à 20:32, Sathvika Vasireddy a écrit :
>>> objtool is throwing *unannotated intra-function call*
>>> warnings with a few instructions that are marked
>>> unreachable. Remove unreachable() from WARN_ON()
>>> to fix these warnings, as the codegen remains same
>>> with and without unreachable() in WARN_ON().
>> Did you try the two exemples described in commit 1e688dd2a3d6
>> ("powerpc/bug: Provide better flexibility to WARN_ON/__WARN_FLAGS() with
>> asm goto") ?
>>
>> Without your patch:
>>
>> 00000640 <test>:
>> 640: 81 23 00 84 lwz r9,132(r3)
>> 644: 71 29 40 00 andi. r9,r9,16384
>> 648: 40 82 00 0c bne 654 <test+0x14>
>> 64c: 80 63 00 0c lwz r3,12(r3)
>> 650: 4e 80 00 20 blr
>> 654: 0f e0 00 00 twui r0,0
>>
>> 00000658 <test9w>:
>> 658: 2c 04 00 00 cmpwi r4,0
>> 65c: 41 82 00 0c beq 668 <test9w+0x10>
>> 660: 7c 63 23 96 divwu r3,r3,r4
>> 664: 4e 80 00 20 blr
>> 668: 0f e0 00 00 twui r0,0
>> 66c: 38 60 00 00 li r3,0
>> 670: 4e 80 00 20 blr
>>
>>
>> With your patch:
>>
>> 00000640 <test>:
>> 640: 81 23 00 84 lwz r9,132(r3)
>> 644: 71 29 40 00 andi. r9,r9,16384
>> 648: 40 82 00 0c bne 654 <test+0x14>
>> 64c: 80 63 00 0c lwz r3,12(r3)
>> 650: 4e 80 00 20 blr
>> 654: 0f e0 00 00 twui r0,0
>> 658: 4b ff ff f4 b 64c <test+0xc> <==
>>
>> 0000065c <test9w>:
>> 65c: 2c 04 00 00 cmpwi r4,0
>> 660: 41 82 00 0c beq 66c <test9w+0x10>
>> 664: 7c 63 23 96 divwu r3,r3,r4
>> 668: 4e 80 00 20 blr
>> 66c: 0f e0 00 00 twui r0,0
>> 670: 38 60 00 00 li r3,0 <==
>> 674: 4e 80 00 20 blr <==
>> 678: 38 60 00 00 li r3,0
>> 67c: 4e 80 00 20 blr
>>
> The builtin variant of unreachable (__builtin_unreachable()) works.
>
> How about using that instead of unreachable() ?
>
>
In fact the problem comes from the macro annotate_unreachable() which is
called by unreachable() before calling __build_unreachable().
Seems like this macro adds (after the unconditional trap twui) a call to
an empty function whose address is listed in section .discard.unreachable
1c78: 00 00 e0 0f twui r0,0
1c7c: 55 e7 ff 4b bl 3d0
<qdisc_root_sleeping_lock.part.0>
RELOCATION RECORDS FOR [.discard.unreachable]:
OFFSET TYPE VALUE
0000000000000000 R_PPC64_REL32 .text+0x00000000000003d0
The problem is that that function has size 0:
00000000000003d0 l F .text 0000000000000000
qdisc_root_sleeping_lock.part.0
And objtool is not prepared for a function with size 0.
The following changes to objtool seem to fix the problem, most warning
are gone with that change.
diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 63218f5799c2..37c0a268b7ea 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -77,6 +77,8 @@ static int symbol_by_offset(const void *key, const
struct rb_node *node)
if (*o < s->offset)
return -1;
+ if (*o == s->offset && !s->len)
+ return 0;
if (*o >= s->offset + s->len)
return 1;
@@ -400,7 +402,7 @@ static void elf_add_symbol(struct elf *elf, struct
symbol *sym)
* Don't store empty STT_NOTYPE symbols in the rbtree. They
* can exist within a function, confusing the sorting.
*/
- if (!sym->len)
+ if (sym->type == STT_NOTYPE && !sym->len)
rb_erase(&sym->node, &sym->sec->symbol_tree);
}
---
I also had objtool running for ever on
arch/powerpc/sysdev/xics/icp-hv.o, which I fixed with the below hack:
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 51b6dcec8d6a..ef2303ad6381 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -529,7 +529,7 @@ static struct instruction *find_last_insn(struct
objtool_file *file,
unsigned int offset;
unsigned int end = (sec->sh.sh_size > 10) ? sec->sh.sh_size - 10 : 0;
- for (offset = sec->sh.sh_size - 1; offset >= end && !insn; offset--)
+ for (offset = sec->sh.sh_size - 1; offset && offset >= end && !insn;
offset--)
insn = find_insn(file, sec, offset);
return insn;
---
Now I only have the following two warnings:
arch/powerpc/sysdev/xics/icp-hv.o: warning: objtool: can't find
unreachable insn at .text.unlikely+0x0
drivers/crypto/vmx/aesp8-ppc.o: warning: objtool:
aes_p8_set_encrypt_key+0x44: unannotated intra-function call
The first one is linked to the infinite loop I hacked. So I now have to
understand what the problem really is.
The second one is an assembly file aesp8-ppc.S which lacks the changes
you did in other assembly files in patch 12.
Christophe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-06-29 18:30 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-24 18:32 [RFC PATCH v3 00/12] objtool: Enable and implement --mcount option on powerpc Sathvika Vasireddy
2022-06-24 18:32 ` Sathvika Vasireddy
2022-06-24 18:32 ` [RFC PATCH v3 01/12] objtool: Fix SEGFAULT Sathvika Vasireddy
2022-06-24 18:32 ` Sathvika Vasireddy
2022-07-08 15:10 ` Christophe Leroy
2022-07-08 15:10 ` Christophe Leroy
2022-06-24 18:32 ` [RFC PATCH v3 02/12] objtool: Use target file endianness instead of a compiled constant Sathvika Vasireddy
2022-06-24 18:32 ` Sathvika Vasireddy
2022-06-24 18:32 ` [RFC PATCH v3 03/12] objtool: Use target file class size " Sathvika Vasireddy
2022-06-24 18:32 ` Sathvika Vasireddy
2022-07-08 17:35 ` Christophe Leroy
2022-07-08 17:35 ` Christophe Leroy
2022-06-24 18:32 ` [RFC PATCH v3 04/12] objtool: Add --mnop as an option to --mcount Sathvika Vasireddy
2022-06-24 18:32 ` Sathvika Vasireddy
2022-06-24 18:32 ` [RFC PATCH v3 05/12] powerpc: Skip objtool from running on VDSO files Sathvika Vasireddy
2022-06-24 18:32 ` Sathvika Vasireddy
2022-06-24 18:32 ` [RFC PATCH v3 06/12] objtool: Read special sections with alts only when specific options are selected Sathvika Vasireddy
2022-06-24 18:32 ` Sathvika Vasireddy
2022-06-24 18:32 ` [RFC PATCH v3 07/12] objtool: Use macros to define arch specific reloc types Sathvika Vasireddy
2022-06-24 18:32 ` Sathvika Vasireddy
2022-07-04 11:14 ` Peter Zijlstra
2022-07-04 11:14 ` Peter Zijlstra
2022-07-04 15:53 ` Christophe Leroy
2022-07-04 15:53 ` Christophe Leroy
2022-07-04 16:18 ` Peter Zijlstra
2022-07-04 16:18 ` Peter Zijlstra
2022-06-24 18:32 ` [RFC PATCH v3 08/12] objtool: Add arch specific function arch_ftrace_match() Sathvika Vasireddy
2022-06-24 18:32 ` Sathvika Vasireddy
2022-06-24 18:32 ` [RFC PATCH v3 09/12] objtool/powerpc: Enable objtool to be built on ppc Sathvika Vasireddy
2022-06-24 18:32 ` Sathvika Vasireddy
2022-06-24 18:32 ` [RFC PATCH v3 10/12] objtool/powerpc: Add --mcount specific implementation Sathvika Vasireddy
2022-06-24 18:32 ` Sathvika Vasireddy
2022-06-24 18:32 ` [RFC PATCH v3 11/12] powerpc: Remove unreachable() from WARN_ON() Sathvika Vasireddy
2022-06-24 18:32 ` Sathvika Vasireddy
2022-06-25 6:46 ` Christophe Leroy
2022-06-25 6:46 ` Christophe Leroy
2022-06-27 15:21 ` Sathvika Vasireddy
2022-06-27 15:35 ` Sathvika Vasireddy
2022-06-27 15:35 ` Sathvika Vasireddy
2022-06-27 15:46 ` Christophe Leroy
2022-06-27 15:46 ` Christophe Leroy
2022-06-29 18:30 ` Christophe Leroy [this message]
2022-06-29 18:30 ` Christophe Leroy
2022-06-29 18:30 ` Christophe Leroy
2022-06-30 8:05 ` Naveen N. Rao
2022-06-30 8:05 ` Naveen N. Rao
2022-06-30 8:05 ` Naveen N. Rao
2022-06-30 9:58 ` Christophe Leroy
2022-06-30 9:58 ` Christophe Leroy
2022-06-30 9:58 ` Christophe Leroy
2022-06-30 10:33 ` Christophe Leroy
2022-06-30 10:33 ` Christophe Leroy
2022-06-30 10:33 ` Christophe Leroy
2022-06-30 10:37 ` Naveen N. Rao
2022-06-30 10:37 ` Naveen N. Rao
2022-06-30 10:37 ` Naveen N. Rao
2022-06-30 15:58 ` Segher Boessenkool
2022-06-30 15:58 ` Segher Boessenkool
2022-06-30 15:58 ` Segher Boessenkool
2022-07-04 12:01 ` Peter Zijlstra
2022-07-04 12:01 ` Peter Zijlstra
2022-07-04 12:01 ` Peter Zijlstra
2022-07-04 11:43 ` Peter Zijlstra
2022-07-04 11:43 ` Peter Zijlstra
2022-07-04 11:43 ` Peter Zijlstra
2022-07-01 2:13 ` Chen Zhongjin
2022-07-01 2:13 ` Chen Zhongjin
2022-07-01 2:13 ` Chen Zhongjin
2022-07-01 6:56 ` Sathvika Vasireddy
2022-07-01 6:56 ` Sathvika Vasireddy
2022-07-01 6:56 ` Sathvika Vasireddy
2022-07-01 11:40 ` [RFC PATCH v3 11/12] powerpc: Remove unreachable() from WARN_ON() (gcc issue ?) Christophe Leroy
2022-07-01 11:40 ` Christophe Leroy
2022-07-01 11:40 ` Christophe Leroy
2022-07-04 11:45 ` [RFC PATCH v3 11/12] powerpc: Remove unreachable() from WARN_ON() Peter Zijlstra
2022-07-04 11:45 ` Peter Zijlstra
2022-07-04 11:45 ` Peter Zijlstra
2022-07-04 12:34 ` Christophe Leroy
2022-07-04 12:34 ` Christophe Leroy
2022-07-04 12:34 ` Christophe Leroy
2022-07-05 15:48 ` Segher Boessenkool
2022-07-05 15:48 ` Segher Boessenkool
2022-07-05 15:48 ` Segher Boessenkool
2022-07-04 12:05 ` Peter Zijlstra
2022-07-04 12:05 ` Peter Zijlstra
2022-07-04 12:44 ` Christophe Leroy
2022-07-04 12:44 ` Christophe Leroy
2022-07-04 14:19 ` Peter Zijlstra
2022-07-04 14:19 ` Peter Zijlstra
2022-06-24 18:32 ` [RFC PATCH v3 12/12] objtool/powerpc: Fix unannotated intra-function call warnings Sathvika Vasireddy
2022-06-24 18:32 ` Sathvika Vasireddy
2022-07-08 15:06 ` [RFC PATCH v3 00/12] objtool: Enable and implement --mcount option on powerpc Christophe Leroy
2022-07-08 15:06 ` Christophe Leroy
2022-07-08 15:42 ` Christophe Leroy
2022-07-08 15:42 ` Christophe Leroy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cce19b1c-449a-f306-533a-9edc855049aa@csgroup.eu \
--to=christophe.leroy@csgroup.eu \
--cc=aik@ozlabs.ru \
--cc=benh@kernel.crashing.org \
--cc=chenzhongjin@huawei.com \
--cc=jpoimboe@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maz@kernel.org \
--cc=mbenes@suse.cz \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=naveen.n.rao@linux.vnet.ibm.com \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sv@linux.ibm.com \
--cc=sv@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.