mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Matt Helsley <mhelsley@vmware.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v3 04/13] recordmcount: Rewrite error/success handling
Date: Fri, 26 Jul 2019 18:37:11 +0000	[thread overview]
Message-ID: <4F0912A7-345E-46EE-B58F-CF7E8EE2AB65@vmware.com> (raw)
In-Reply-To: <20190726134523.4e7afd55@gandalf.local.home>



> On Jul 26, 2019, at 10:45 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> On Wed, 24 Jul 2019 14:04:58 -0700
> Matt Helsley <mhelsley@vmware.com> wrote:
> 
> 
> Hi Matt,
> 
> As I'm applying these for real, I'm taking a deeper look at the
> patches. This one I have some questions about.
> 
>> Recordmcount uses setjmp/longjmp to manage control flow as
>> it reads and then writes the ELF file. This unusual control
>> flow is hard to follow and check in addition to being unlike
>> kernel coding style.
>> 
>> So we rewrite these paths to use regular return values to
>> indicate error/success. When an error or previously-completed object
>> file is found we return an error code following kernel
>> coding conventions -- negative error values and 0 for success when
>> we're not returning a pointer. We return NULL for those that fail
>> and return non-NULL pointers otherwise.
>> 
>> One oddity is already_has_rel_mcount -- there we use pointer comparison
>> rather than string comparison to differentiate between
>> previously-processed object files and returning the name of a text
>> section.
> 
> This is fine, but it's got a strange implementation.
> 
> 
> 
>> diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h
>> index c1e1b04b4871..909a3e4775c2 100644
>> --- a/scripts/recordmcount.h
>> +++ b/scripts/recordmcount.h
>> @@ -24,7 +24,9 @@
>> #undef mcount_adjust
>> #undef sift_rel_mcount
>> #undef nop_mcount
>> +#undef missing_sym
>> #undef find_secsym_ndx
>> +#undef already_has_rel_mcount
> 
> Why do we need these as defines? Can't you just have a single:
> 
> const char *already_has_mcount = "success";
> 
> in recordmcount.c before recordmcount.h is included?
> 
> And same for missing_sym.

Yes, that’s a good point. I’ve been trying to separate the changes to the functions
from moving parts out but in this case it would make just as much sense to add them to recordmcount.c in the first place.

Ultimately, this ugliness gets removed as the next series removes recordmcount.h entirely and one of the steps is moving find_secsym_ndx() out while eliminating these redundant pieces.

> 
> Another, probably more robust way of doing this, is change
> find_secsym_ndx() to return 0 on success and -1 on missing symbol, and
> just pass a pointer by reference to fill the recsym (which doesn't have
> to be a constant).

That’s easy enough to do  and  I do like separating the error/success return from returning  the index. I can send that out now or tack it onto the next RFC series I’m about to send which completes the conversion if that’s preferable.

Yeah, the original code applies “const” in lots of places -- I presume it’s an attempt to eek out every last bit of performance from the compiler.

Cheers,
     -Matt

  reply	other threads:[~2019-07-26 18:37 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-24 21:04 [PATCH v3 00/13] Cleanup recordmcount and begin objtool conversion Matt Helsley
2019-07-24 21:04 ` [PATCH v3 01/13] recordmcount: Remove redundant strcmp Matt Helsley
2019-07-24 21:04 ` [PATCH v3 02/13] recordmcount: Remove uread() Matt Helsley
2019-07-24 21:04 ` [PATCH v3 03/13] recordmcount: Remove unused fd from uwrite() and ulseek() Matt Helsley
2019-07-24 21:04 ` [PATCH v3 04/13] recordmcount: Rewrite error/success handling Matt Helsley
2019-07-26 17:45   ` Steven Rostedt
2019-07-26 18:37     ` Matt Helsley [this message]
2019-07-26 18:43       ` Steven Rostedt
2019-07-26 19:23         ` Matt Helsley
2019-07-24 21:04 ` [PATCH v3 05/13] recordmcount: Kernel style function signature formatting Matt Helsley
2019-07-24 21:05 ` [PATCH v3 06/13] recordmcount: Kernel style formatting Matt Helsley
2019-07-24 21:05 ` [PATCH v3 07/13] recordmcount: Remove redundant cleanup() calls Matt Helsley
2019-07-24 21:05 ` [PATCH v3 08/13] recordmcount: Clarify what cleanup() does Matt Helsley
2019-07-26 16:10   ` Steven Rostedt
2019-07-26 16:13   ` Steven Rostedt
2019-07-24 21:05 ` [PATCH v3 09/13] objtool: Prepare to merge recordmcount Matt Helsley
2019-07-28 17:48   ` Josh Poimboeuf
2019-07-29 20:10     ` Matt Helsley
2019-07-24 21:05 ` [PATCH v3 10/13] objtool: Make recordmcount into an objtool subcmd Matt Helsley
2019-07-28 17:48   ` Josh Poimboeuf
2019-07-29 20:19     ` Matt Helsley
2019-07-24 21:05 ` [PATCH v3 11/13] objtool: recordmcount: Start using objtool's elf wrapper Matt Helsley
2019-07-24 21:05 ` [PATCH v3 12/13] objtool: recordmcount: Search for __mcount_loc before walking the sections Matt Helsley
2019-07-24 21:05 ` [PATCH v3 13/13] objtool: recordmcount: Convert do_func() relhdrs Matt Helsley
2019-07-28 17:52 ` [PATCH v3 00/13] Cleanup recordmcount and begin objtool conversion 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=4F0912A7-345E-46EE-B58F-CF7E8EE2AB65@vmware.com \
    --to=mhelsley@vmware.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.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