From: Jens Remus <jremus@linux.ibm.com>
To: Indu Bhagat <indu.bhagat@oracle.com>, binutils@sourceware.org
Cc: Andreas Krebbel <krebbel@linux.ibm.com>
Subject: Re: [PATCH v3 15/15] gas: Validate SFrame RA tracking and fixed RA offset
Date: Mon, 6 May 2024 16:39:24 +0200 [thread overview]
Message-ID: <8881ba96-d1f4-41ca-a645-138cf6647ef1@linux.ibm.com> (raw)
In-Reply-To: <6445f04c-1cb8-4b44-988f-b57f30cb4f69@linux.ibm.com>
Am 06.05.2024 um 13:41 schrieb Jens Remus:
> Am 04.05.2024 um 02:22 schrieb Indu Bhagat:
>> On 5/3/24 09:40, Jens Remus wrote:
>>> Am 18.04.2024 um 22:38 schrieb Indu Bhagat:
>>>> On 4/12/24 07:47, Jens Remus wrote:
>>>>> If an architecture uses SFrame return-address (RA) tracking it must
>>>>> specify the fixed RA offset as invalid. Otherwise, if an architecture
>>>>> does not use RA tracking, it must specify a valid fixed RA offset.
>>>>>
>>>>> gas/
>>>>> * gen-sframe.c: Validate SFrame RA tracking and fixed
>>>>> RA offset.
>>>>>
>>>>> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
>>>>> ---
>>>>>
>>>>> Notes (jremus):
>>>>> Changes v2 -> v3:
>>>>> - New patch.
>>>>> This could be made dependent on ENABLE_CHECKING (configure option
>>>>> --enable-checking).
>>>>>
>>>>> gas/gen-sframe.c | 12 ++++++++++++
>>>>> 1 file changed, 12 insertions(+)
>>>>>
>>>>> diff --git a/gas/gen-sframe.c b/gas/gen-sframe.c
>>>>> index ca6565b0e45e..7e815f9603ef 100644
>>>>> --- a/gas/gen-sframe.c
>>>>> +++ b/gas/gen-sframe.c
>>>>> @@ -1532,6 +1532,18 @@ output_sframe (segT sframe_seg)
>>>>> /* Setup the version specific access functions. */
>>>>> sframe_set_version (SFRAME_VERSION_2);
>>>>> +#ifdef SFRAME_FRE_RA_TRACKING
>>>>> + if (sframe_ra_tracking_p ())
>>>>> + /* With RA tracking the fixed RA offset must be invalid. */
>>>>> + gas_assert (sframe_cfa_ra_offset () ==
>>>>> SFRAME_CFA_FIXED_RA_INVALID);
>>>>> + else
>>>>> + /* Without RA tracking the fixed RA offset may not be
>>>>> invalid. */
>>>>> + gas_assert (sframe_cfa_ra_offset () !=
>>>>> SFRAME_CFA_FIXED_RA_INVALID);
>>>>> +#else
>>>>> + /* Without RA tracking the fixed RA offset may not be invalid. */
>>>>> + gas_assert (sframe_cfa_ra_offset () !=
>>>>> SFRAME_CFA_FIXED_RA_INVALID);
>>>>> +#endif
>>>>> +
>>>>
>>>> I am not sure if the detailed checks are worth it here (simply
>>>> because of code patterns that follow).
>>>
>>> I agree, provided the checks are performed elsewhere as you suggest.
>>>
>>> My intention was to have checks that assist with getting SFrame
>>> support for another architecture implemented correctly, without
>>> having to chase subtle issues.
>>>
>>>>
>>>> We use the sframe_cfa_ra_offset () function later and only in
>>>> output_sframe_internal () (shown below). How about we simply put an
>>>> assert there (and get rid of the proposed thunk above):
>>>>
>>>> #ifdef sframe_ra_tracking_p
>>>> if (!sframe_ra_tracking_p ())
>>>
>>> See below.
>>>
>>>> {
>>>> fixed_ra_offset = sframe_cfa_ra_offset ();
>>>> gas_assert (fixed_ra_offset != SFRAME_CFA_FIXED_RA_INVALID);
>>>
>>> That is clever and accounts for one potential implementation issue!
>>>
>>>> }
>>>> #endif
>>>> out_one (fixed_ra_offset);
>>>>
>>>> fixed_ra_offset is initialized to SFRAME_CFA_FIXED_RA_INVALID in
>>>> output_sframe_internal ().
>>>
>>> Above logic requires sframe_ra_tracking_p to be defined by an
>>> architecture that is not using RA tracking. Not defining
>>> sframe_ra_tracking_p would result in fixed_ra_offset being
>>> unexpectedly initialized to SFRAME_CFA_FIXED_RA_INVALID instead of
>>> being set to sframe_cfa_ra_offset().
>>>
>>> All checks but this do test SFRAME_FRE_RA_TRACKING first, which
>>> ensures both sframe_ra_tracking_p and SFRAME_CFA_RA_REG are defined,
>>> and then the predicate sframe_ra_tracking_p to determine whether RA
>>> tracking is used.
>>> If SFRAME_FRE_RA_TRACKING is defined and sframe_ra_tracking_p returns
>>> true, then RA tracking is used.
>>> Likewise, if SFRAME_FRE_RA_TRACKING is not defined or if
>>> sframe_ra_tracking_p returns false (evaluating lazily) RA tracking is
>>> not used.
>>>
>>> What about making the following change to make all RA tracking tests
>>> consistent depend on SFRAME_FRE_RA_TRACKING?
>>>
>>> #ifdef SFRAME_FRE_RA_TRACKING
>>> if (!sframe_ra_tracking_p ())
>>> #endif
>>> {
>>> fixed_ra_offset = sframe_cfa_ra_offset ();
>>> /* Without RA tracking the fixed RA offset may not be
>>> invalid. */
>>> gas_assert (fixed_ra_offset != SFRAME_CFA_FIXED_RA_INVALID);
>>> }
>>> out_one (fixed_ra_offset);
>>>
>>
>> Oops, that's my bad. Guarding with SFRAME_FRE_RA_TRACKING is more
>> appropriate.
>
> Included this in the previous patch in this series.
This breaks x86-64, as gas/config/tc-i386.h does not define SFRAME_CFA_RA_REG.
Either this specific check must stay, possibly with an additional comment:
/* Offset for the return address from CFA is fixed for some ABIs
(e.g., AMD64), output a SFRAME_CFA_FIXED_RA_INVALID otherwise.
NOTE: sframe_ra_tracking_p may be defined without SFRAME_CFA_RA_REG
(e.g., AMD64), so that SFRAME_FRE_RA_TRACKING won't be defined. */
#ifdef sframe_ra_tracking_p
if (!sframe_ra_tracking_p ())
{
fixed_ra_offset = sframe_cfa_ra_offset ();
/* Without RA tracking the fixed RA offset may not be invalid. */
gas_assert (fixed_ra_offset != SFRAME_CFA_FIXED_RA_INVALID);
}
#endif
out_one (fixed_ra_offset);
or gas/config/tc-i386.h needs to define SFRAME_CFA_RA_REG, for instance as follows:
#define SFRAME_CFA_RA_REG DWARF2_DEFAULT_RETURN_COLUMN
Since an architecture may not have a RA register I wonder whether keeping the existing logic as is would be better. What is your opinion?
>
>>
>> But, I think calling the sframe_cfa_ra_offset () out of
>> SFRAME_FRE_RA_TRACKING portrays an imprecise meaning. Only backends
>> which opt in for SFrame define these vars/functions. (The cross build
>> will likely pass because of the way code is written, but I think you
>> get the idea).
>>
>> I would do:
>>
>> #ifdef SFRAME_FRE_RA_TRACKING
>> if (!sframe_ra_tracking_p ())
>> {
>> fixed_ra_offset = sframe_cfa_ra_offset ();
>> /* Without RA tracking the fixed RA offset may not be
>> invalid. */
>> gas_assert (fixed_ra_offset != SFRAME_CFA_FIXED_RA_INVALID);
>> }
>> #endif
>> out_one (fixed_ra_offset);
>
> Good catch! I did not consider that SFrame may not be implemented by an
> architecture at all.
>
>>
>>
>>> What would still not be checked is the implementation error to define
>>> sframe_ra_tracking_p and have it return true without also defining
>>> SFRAME_CFA_RA_REG. This would be treated as if RA tracking was not used.
>>>
>>> Would it therefore make sense to add the following?
>>>
>>> #if defined (sframe_ra_tracking_p) && !defined (SFRAME_CFA_RA_REG)
>>> gas_assert (!sframe_ra_tracking_p ())
>>> #endif
>>>
>>> Also when using RA tracking an architecture should implement
>>> sframe_cfa_ra_offset to return SFRAME_CFA_FIXED_RA_INVALID.
>>>
>>> Would it therefore make sense to add the following?
>>>
>>> #ifdef SFRAME_FRE_RA_TRACKING
>>> if (sframe_ra_tracking_p ())
>>> gas_assert (sframe_cfa_ra_offset () ==
>>> SFRAME_CFA_FIXED_RA_INVALID);
>>> #endif
>>>
>>
>> All these checks are around guarding against implementation errors,
>> opinions may vary. If you feel these add value, then it makes sense to
>> add them.
>>
>> (That said, I am thinking the name sframe_cfa_ra_offset is confusing;
>> perhaps sframe_cfa_ra_fixed_offset () is better? I will think about it
>> and may be include this in my list of sframe-next patches.)
>
> I'll leave it up to you then.
>
>>
>>>>
>>>>> /* Process all fdes and create SFrame stack trace information. */
>>>>> create_sframe_all ();
>>>>
>>>
>>> Thanks and regards,
>>> Jens
>>
>
> Regards,
> Jens
Thanks and regards,
Jens
--
Jens Remus
Linux on Z Development (D3303) and z/VSE Support
+49-7031-16-1128 Office
jremus@de.ibm.com
IBM
IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Böblingen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/
next prev parent reply other threads:[~2024-05-06 14:44 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-12 14:47 [PATCH v3 00/15] sframe: Enhancements to SFrame info generation Jens Remus
2024-04-12 14:47 ` [PATCH v3 01/15] x86: Remove unused SFrame CFI RA register variable Jens Remus
2024-04-12 14:47 ` [PATCH v3 02/15] gas: Enhance arch-specific SFrame configuration descriptions Jens Remus
2024-04-18 7:39 ` Indu Bhagat
2024-05-03 12:30 ` Jens Remus
2024-04-12 14:47 ` [PATCH v3 03/15] readelf/objdump: Dump SFrame CFA fixed FP and RA offsets Jens Remus
2024-04-18 7:39 ` Indu Bhagat
2024-04-12 14:47 ` [PATCH v3 04/15] readelf/objdump: Display SFrame fixed RA offset as 'f' in dump Jens Remus
2024-04-18 7:40 ` Indu Bhagat
2024-04-12 14:47 ` [PATCH v3 05/15] gas: Print DWARF call frame insn name in SFrame warning message Jens Remus
2024-04-18 7:40 ` Indu Bhagat
2024-04-12 14:47 ` [PATCH v3 06/15] gas: Skip SFrame FDE if CFI specifies non-FP/SP base register Jens Remus
2024-04-18 7:40 ` Indu Bhagat
2024-04-12 14:47 ` [PATCH v3 07/15] gas: Warn if SFrame FDE is skipped due to non-default return column Jens Remus
2024-04-18 7:40 ` Indu Bhagat
2024-04-12 14:47 ` [PATCH v3 08/15] gas: Refactor SFrame CFI opcode DW_CFA_register processing Jens Remus
2024-04-18 7:40 ` Indu Bhagat
2024-04-12 14:47 ` [PATCH v3 09/15] gas: User readable warnings if SFrame FDE is not generated Jens Remus
2024-04-18 20:33 ` Indu Bhagat
2024-05-03 12:30 ` Jens Remus
2024-05-03 23:41 ` Indu Bhagat
2024-04-12 14:47 ` [PATCH v3 10/15] gas: Skip SFrame FDE if FP without RA on stack Jens Remus
2024-04-16 13:14 ` Jens Remus
2024-04-17 23:56 ` Indu Bhagat
2024-04-18 10:27 ` Jens Remus
2024-04-18 20:35 ` Indu Bhagat
2024-04-12 14:47 ` [PATCH v3 11/15] gas: Skip SFrame FDE if .cfi_window_save Jens Remus
2024-04-18 20:36 ` Indu Bhagat
2024-04-12 14:47 ` [PATCH v3 12/15] gas: Don't skip SFrame FDE if .cfi_register specifies RA w/o tracking Jens Remus
2024-04-18 20:36 ` Indu Bhagat
2024-04-12 14:47 ` [PATCH v3 13/15] gas: Don't skip SFrame FDE if .cfi_register specifies SP register Jens Remus
2024-04-18 20:37 ` Indu Bhagat
2024-04-19 13:13 ` Jens Remus
2024-04-23 8:15 ` Indu Bhagat
2024-04-25 22:22 ` Indu Bhagat
2024-04-12 14:47 ` [PATCH v3 14/15] gas: Test predicate whether SFrame RA tracking is used Jens Remus
2024-04-18 20:37 ` Indu Bhagat
2024-04-12 14:47 ` [PATCH v3 15/15] gas: Validate SFrame RA tracking and fixed RA offset Jens Remus
2024-04-18 20:38 ` Indu Bhagat
2024-05-03 16:40 ` Jens Remus
2024-05-04 0:22 ` Indu Bhagat
2024-05-06 11:41 ` Jens Remus
2024-05-06 14:39 ` Jens Remus [this message]
2024-05-16 20:45 ` Indu Bhagat
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=8881ba96-d1f4-41ca-a645-138cf6647ef1@linux.ibm.com \
--to=jremus@linux.ibm.com \
--cc=binutils@sourceware.org \
--cc=indu.bhagat@oracle.com \
--cc=krebbel@linux.ibm.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).