From: Peter Zijlstra <peterz@infradead.org>
To: Indu Bhagat <indu.bhagat@oracle.com>
Cc: linux-toolchains@vger.kernel.org, daandemeyer@meta.com,
andrii@kernel.org, rostedt@goodmis.org, kris.van.hees@oracle.com,
elena.zannoni@oracle.com, nick.alcock@oracle.com
Subject: Re: [POC 3/5] sframe: add new SFrame library
Date: Tue, 2 May 2023 11:20:06 +0200 [thread overview]
Message-ID: <20230502092006.GJ1597476@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20230501200410.3973453-4-indu.bhagat@oracle.com>
On Mon, May 01, 2023 at 01:04:08PM -0700, Indu Bhagat wrote:
> +static unsigned int sframe_get_fre_type(struct sframe_func_desc_entry *fdep)
> +{
> + return (fdep) ? SFRAME_V1_FUNC_FRE_TYPE(fdep->func_info) : 0;
> +}
> +
> +static unsigned int sframe_get_fde_type(struct sframe_func_desc_entry *fdep)
> +{
> + return (fdep) ? SFRAME_V1_FUNC_FDE_TYPE(fdep->func_info) : 0;
> +}
vs.
> +unsigned int sframe_fre_get_base_reg_id(struct sframe_fre *frep,
> + int *errp)
> +{
> + if (!frep)
> + return sframe_set_errno(errp, SFRAME_ERR_FRE_INVAL);
> +
> + return SFRAME_V1_FRE_CFA_BASE_REG_ID(frep->fre_info);
> +}
Inconsistent codying style here... FWIW, I prefer the latter.
> +int32_t sframe_fre_get_fp_offset(struct sframe_sec *sfsec,
> + struct sframe_fre *frep, int *errp)
> +{
> + uint32_t fp_offset_idx = 0;
There's an unconditional assignment later, why are you initializing to 0
here? Also, that xmas thing Steve mentioned.
> + int8_t fp_offset = sframe_sec_get_fixed_fp_offset(sfsec);
> + /*
> + * If the FP offset is not being tracked, return the fixed FP offset
> + * from the SFrame header.
> + */
> + if (fp_offset != SFRAME_CFA_FIXED_FP_INVALID) {
> + *errp = 0;
> + return fp_offset;
> + }
> +
> + /*
> + * In some ABIs, the stack offset to recover RA (using the CFA) from is
> + * fixed (like AMD64). In such cases, the stack offset to recover FP
> + * will appear at the second index.
> + */
> + fp_offset_idx = ((sframe_sec_get_fixed_ra_offset(sfsec)
> + != SFRAME_CFA_FIXED_RA_INVALID)
> + ? SFRAME_FRE_RA_OFFSET_IDX
> + : SFRAME_FRE_FP_OFFSET_IDX);
And as such, I'll suggest you write this like:
fp_offset_idx = SFRAME_FRE_FP_OFFSET_IDX;
if (sframe_sec_get_fixed_ra_offset(sfrec) != SFRAME_CFA_FIXED_RA_INVALID)
fp_offset_idx = SFRAME_FRE_RA_OFFSET_IDX;
And also, if you'd use shorter identifiers, you'd not constantly run
into the line limit like you do.
Basically never use ?: unless you _have_ to :-)
> + return sframe_get_fre_offset(frep, fp_offset_idx, errp);
> +}
next prev parent reply other threads:[~2023-05-02 9:20 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-01 20:04 [POC 0/5] SFrame based stack tracer for user space in the kernel Indu Bhagat
2023-05-01 20:04 ` [POC 1/5] Kconfig: x86: Add new config options for userspace unwinder Indu Bhagat
2023-05-01 20:04 ` [POC 2/5] task_struct : add additional member for sframe state Indu Bhagat
2023-05-01 20:04 ` [POC 3/5] sframe: add new SFrame library Indu Bhagat
2023-05-01 22:40 ` Steven Rostedt
2023-05-02 5:07 ` Indu Bhagat
2023-05-02 8:46 ` Peter Zijlstra
2023-05-02 9:09 ` Peter Zijlstra
2023-05-02 9:20 ` Peter Zijlstra [this message]
2023-05-02 9:28 ` Peter Zijlstra
2023-05-02 9:30 ` Peter Zijlstra
2023-05-03 6:03 ` Indu Bhagat
2023-05-02 10:31 ` Peter Zijlstra
2023-05-02 10:41 ` Peter Zijlstra
2023-05-02 15:22 ` Steven Rostedt
2023-05-01 20:04 ` [POC 4/5] sframe: add an SFrame format stack tracer Indu Bhagat
2023-05-01 23:00 ` Steven Rostedt
2023-05-02 6:16 ` Indu Bhagat
2023-05-02 8:53 ` Peter Zijlstra
2023-05-02 9:04 ` Peter Zijlstra
2023-05-01 20:04 ` [POC 5/5] x86_64: invoke SFrame based stack tracer for user space Indu Bhagat
2023-05-01 23:11 ` Steven Rostedt
2023-05-02 10:53 ` Peter Zijlstra
2023-05-02 15:27 ` Steven Rostedt
2023-05-16 17:25 ` Andrii Nakryiko
2023-05-16 17:38 ` Steven Rostedt
2023-05-16 17:51 ` Andrii Nakryiko
2024-03-13 14:37 ` Tatsuyuki Ishi
2024-03-13 14:52 ` Steven Rostedt
2024-03-13 14:58 ` Tatsuyuki Ishi
2024-03-13 15:04 ` Steven Rostedt
2023-05-01 22:15 ` [POC 0/5] SFrame based stack tracer for user space in the kernel Steven Rostedt
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=20230502092006.GJ1597476@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=andrii@kernel.org \
--cc=daandemeyer@meta.com \
--cc=elena.zannoni@oracle.com \
--cc=indu.bhagat@oracle.com \
--cc=kris.van.hees@oracle.com \
--cc=linux-toolchains@vger.kernel.org \
--cc=nick.alcock@oracle.com \
--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;
as well as URLs for NNTP newsgroup(s).