From: Nicholas Mc Guire <der.herr@hofr.at>
To: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
sil2review@lists.osadl.org, Jiri Slaby <jslaby@suse.cz>,
Ingo Molnar <mingo@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [SIL2review] [PATCH] objtool: Use value of intended enum to compile with clang
Date: Sun, 10 Dec 2017 20:19:03 +0000 [thread overview]
Message-ID: <20171210201903.GA13846@osadl.at> (raw)
In-Reply-To: <1512930902-15731-2-git-send-email-lukas.bulwahn@gmail.com>
On Sun, Dec 10, 2017 at 07:35:00PM +0100, Lukas Bulwahn wrote:
> Just use the right value and avoid an implicit conversion between the two
> enumeration types that just happened to work in this case. It seems that
> this must have just been overlooked in the new implementation of objtool
> in commit baa41469a7b9 ("objtool: Implement stack validation 2.0").
>
> I found this when compiling the kernel with clang-5.0, i.e., executing
>
> make HOSTCC=clang-5.0 CC=clang-5.0 defconfig && \
> make HOSTCC=clang-5.0 CC=clang-5.0
>
> fails with:
>
> ```
> arch/x86/decode.c:141:20: error: implicit conversion from enumeration type 'enum op_src_type' to different enumeration type 'enum op_dest_type' [-Werror,-Wenum-conversion]
> op->dest.type = OP_SRC_REG;
> ~ ^~~~~~~~~~
> 1 error generated.
> ```
given the declaration in tools/objtool/arch.h
enum op_dest_type {
OP_DEST_REG,
...
enum op_src_type {
OP_SRC_REG,
...
the change seems correct and it is clear why it worked with the wrong type
>
> Fixes: baa41469a7b9 ("objtool: Implement stack validation 2.0")
> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Reviewed-by: Nicholas Mc Guire <der.herr@hofr.at>
> ---
> tools/objtool/arch/x86/decode.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decode.c
> index 8acfc47..540a209 100644
> --- a/tools/objtool/arch/x86/decode.c
> +++ b/tools/objtool/arch/x86/decode.c
> @@ -138,7 +138,7 @@ int arch_decode_instruction(struct elf *elf, struct section *sec,
> *type = INSN_STACK;
> op->src.type = OP_SRC_ADD;
> op->src.reg = op_to_cfi_reg[modrm_reg][rex_r];
> - op->dest.type = OP_SRC_REG;
> + op->dest.type = OP_DEST_REG;
> op->dest.reg = CFI_SP;
> }
> break;
> --
> 2.7.4
>
> _______________________________________________
> SIL2review mailing list
> SIL2review@lists.osadl.org
> https://lists.osadl.org/mailman/listinfo/sil2review
prev parent reply other threads:[~2017-12-10 20:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-10 18:34 Lukas Bulwahn
2017-12-10 18:35 ` [PATCH] " Lukas Bulwahn
2017-12-10 20:19 ` Nicholas Mc Guire [this message]
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=20171210201903.GA13846@osadl.at \
--to=der.herr@hofr.at \
--cc=jpoimboe@redhat.com \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas.bulwahn@gmail.com \
--cc=mingo@kernel.org \
--cc=sil2review@lists.osadl.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome