[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <936a4873-bfe6-cabc-fa63-b8ba14857243@loongson.cn>
Date: Thu, 27 Jul 2023 18:58:20 +0800
From: Tiezhu Yang <yangtiezhu@...ngson.cn>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Josh Poimboeuf <jpoimboe@...nel.org>,
Huacai Chen <chenhuacai@...nel.org>, loongarch@...ts.linux.dev,
linux-kernel@...r.kernel.org, loongson-kernel@...ts.loongnix.cn
Subject: Re: [PATCH v1 4/6] objtool/LoongArch: Enable orc to be built
On 07/25/2023 07:51 PM, Peter Zijlstra wrote:
> On Tue, Jul 25, 2023 at 04:15:08PM +0800, Tiezhu Yang wrote:
>
> Previous Changelog had:
>
>> Define update_cfi_state() as a weak function which may be overwritten
>> by the arch-specific implementation.
>
> And then this patch does:
>
>> +int update_cfi_state(struct instruction *insn,
>> + struct instruction *next_insn,
>> + struct cfi_state *cfi, struct stack_op *op)
>> +{
>> + struct cfi_reg *cfa = &cfi->cfa;
>> + struct cfi_reg *regs = cfi->regs;
...
>> + default:
>> + WARN_FUNC("unknown stack-related instruction", insn->sec, insn->offset);
>> + return -1;
>> + }
>> +
>> + return 0;
>> +}
>
> Why ?!? what is the actual irreconcilable difference?
I went in deeper to analysis the code and did more test,
the conclusion is that there is no need to define the
arch-specific update_cfi_state(), although it seems simpler
than the generic update_cfi_state(), the generic function
can handle all the cases and works well.
> If you want us to review this, you'll have to explain things.
I will drop the related changes in the next version, thank you.
Thanks,
Tiezhu
Powered by blists - more mailing lists