All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Thierry <jthierry@redhat.com>
To: Miroslav Benes <mbenes@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
	peterz@infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/4] objtool: Move orc outside of check
Date: Fri, 31 Jul 2020 09:19:27 +0100	[thread overview]
Message-ID: <c3b0636e-3f32-8349-3e86-277da8c54606@redhat.com> (raw)
In-Reply-To: <alpine.LSU.2.21.2007310949020.19678@pobox.suse.cz>



On 7/31/20 8:56 AM, Miroslav Benes wrote:
> On Thu, 30 Jul 2020, Julien Thierry wrote:
> 
>>
>>
>> On 7/30/20 3:15 PM, Josh Poimboeuf wrote:
>>> On Thu, Jul 30, 2020 at 02:29:20PM +0100, Julien Thierry wrote:
>>>>
>>>>
>>>> On 7/30/20 2:22 PM, peterz@infradead.org wrote:
>>>>> On Thu, Jul 30, 2020 at 01:40:42PM +0100, Julien Thierry wrote:
>>>>>>
>>>>>>
>>>>>> On 7/30/20 10:57 AM, peterz@infradead.org wrote:
>>>>>>> On Thu, Jul 30, 2020 at 10:41:41AM +0100, Julien Thierry wrote:
>>>>>>>> +		if (file->elf->changed)
>>>>>>>> +			return elf_write(file->elf);
>>>>>>>> +		else
>>>>>>>> +			return 0;
>>>>>>>>       }
>>>>>>>
>>>>>>> I think we can do without that else :-)
>>>>>>>
>>>>>>
>>>>>> I did wonder and was not 100% confident about it, but the orc gen will
>>>>>> always change the file, correct?
>>>>>
>>>>> Not if it already has orc, iirc.
>>>>>
>>>>> But what I was trying to say is that:
>>>>>
>>>>>   if (file->elf->changed)
>>>>>    return elf_write(file->elf)
>>>>>
>>>>>   return 0;
>>>>>
>>>>> is identical code and, IMO, easier to read.
>>>>>
>>>>
>>>> Much easier yes, I'll change it.
>>>
>>> But I think file->elf->changed can be assumed at this point anyway, so
>>> it could just be an unconditional
>>>
>>>   return elf_write(file->elf);
>>>
>>
>> I'll triple check whether that's the case and remove the if if possible.
> 
> I think it is the case. And even if not, it would only cause a pointless
> call to elf_update() in the end and that should not do any harm anyway if
> I am not mistaken.
> 
> However, I think there is a problem with the rebase on top of the current
> code. The patch moves elf_write() call to orc_gen.c which was ok before
> Peterz introduced elf_write_insn() et al. We need to keep elf_write() in
> check.c for this case too.
> 

Yes, you're right. Looks like I messed things up with the rebase. That 
means I might have to move the elf_write() to builtin-check.c.

Thanks for pointing it out.

-- 
Julien Thierry


  reply	other threads:[~2020-07-31  8:19 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-30  9:41 [PATCH v3 0/4] Remove dependency of check subcmd upon orc Julien Thierry
2020-07-30  9:41 ` [PATCH v3 1/4] objtool: Move object file loading out of check Julien Thierry
2020-07-30 14:09   ` Josh Poimboeuf
2020-07-30 14:42     ` Julien Thierry
2020-07-30  9:41 ` [PATCH v3 2/4] objtool: Move orc outside " Julien Thierry
2020-07-30  9:57   ` peterz
2020-07-30 12:40     ` Julien Thierry
2020-07-30 13:22       ` peterz
2020-07-30 13:29         ` Julien Thierry
2020-07-30 14:15           ` Josh Poimboeuf
2020-07-30 14:44             ` Julien Thierry
2020-07-31  7:56               ` Miroslav Benes
2020-07-31  8:19                 ` Julien Thierry [this message]
2020-07-30  9:41 ` [PATCH v3 3/4] objtool: orc: Skip setting orc_entry for non-text sections Julien Thierry
2020-07-30  9:41 ` [PATCH v3 4/4] objtool: orc_gen: Move orc_entry out of instruction structure Julien Thierry
2020-07-30 10:03   ` peterz
2020-07-30 12:40     ` Julien Thierry
2020-07-30 13:33       ` peterz
2020-07-30 13:45         ` Julien Thierry
2020-07-30 14:28           ` Josh Poimboeuf
2020-07-30 14:06 ` [PATCH v3 0/4] Remove dependency of check subcmd upon orc Josh Poimboeuf
2020-07-30 14:42   ` Julien Thierry
2020-07-30 15:05     ` Josh Poimboeuf

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=c3b0636e-3f32-8349-3e86-277da8c54606@redhat.com \
    --to=jthierry@redhat.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=peterz@infradead.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 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.