public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Matthew Malcomson <matmal01@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc(refs/vendors/ARM/heads/morello)] libgcc type handling. Date: Mon, 14 Mar 2022 10:35:52 +0000 (GMT) [thread overview] Message-ID: <20220314103552.DC2F6385E442@sourceware.org> (raw) https://gcc.gnu.org/g:724db4b6920f23db62ad3a21abcc1908d8fe3ccf commit 724db4b6920f23db62ad3a21abcc1908d8fe3ccf Author: Matthew Malcomson <matthew.malcomson@arm.com> Date: Mon Mar 7 18:04:40 2022 +0000 libgcc type handling. Here we update various places throughout the FDE searching code using PC addresses. With the introduction of the distinction between an address and a pointer for capability architectures this has gotten a little unclear. The reasoning behind these changes is as follows: - read_encoded_value_with_base must be able to read in a capability, since we use that functionality for reading personality functions and landing pads. Hence all variables which we read in using that function should have a capability type. - The PC addresses are never written as capabilities directly. Hence reading in the addresses directly into capability types is a bit of a red flag. The existing code did this in a few different places when the encoding of the FDE was DW_EH_PE_absptr. This clause won't be entered for pure capability architectures, but it still makes for code which looks problematic to the reader. Hence we switch the types here to be addresses, which are fine in both capability and non-capability architectures. - The ob->pc_begin member *is* kept as a capability for no real reason other than consistency with the other `struct object` members which are `void *`. While reading in the PC start addresses of FDE's we could end up with a capability if the address is encoded in the right way, hence this member could end up containing a capability, but it's still only used for checking positions and hence could be an address. Diff: --- libgcc/unwind-dw2-fde.c | 38 +++++++++++++++++++++----------------- 1 file changed, 21 insertions(+), 17 deletions(-) diff --git a/libgcc/unwind-dw2-fde.c b/libgcc/unwind-dw2-fde.c index 26be05d4aca..b58b381fd1a 100644 --- a/libgcc/unwind-dw2-fde.c +++ b/libgcc/unwind-dw2-fde.c @@ -361,9 +361,9 @@ static int fde_unencoded_compare (struct object *ob __attribute__((unused)), const fde *x, const fde *y) { - _Unwind_Ptr x_ptr, y_ptr; - memcpy (&x_ptr, x->pc_begin, sizeof (_Unwind_Ptr)); - memcpy (&y_ptr, y->pc_begin, sizeof (_Unwind_Ptr)); + _Unwind_Address x_ptr, y_ptr; + memcpy (&x_ptr, x->pc_begin, sizeof (_Unwind_Address)); + memcpy (&y_ptr, y->pc_begin, sizeof (_Unwind_Address)); if (x_ptr > y_ptr) return 1; @@ -721,8 +721,8 @@ add_fdes (struct object *ob, struct fde_accumulator *accu, const fde *this_fde) if (encoding == DW_EH_PE_absptr) { - _Unwind_Ptr ptr; - memcpy (&ptr, this_fde->pc_begin, sizeof (_Unwind_Ptr)); + _Unwind_Address ptr; + memcpy (&ptr, this_fde->pc_begin, sizeof (_Unwind_Address)); if (ptr == 0) continue; } @@ -866,7 +866,7 @@ linear_search_fdes (struct object *ob, const fde *this_fde, _Unwind_Address pc) } else { - _Unwind_Ptr mask; + _Unwind_Address mask; const unsigned char *p; p = read_encoded_value_with_base (encoding, base, @@ -876,9 +876,13 @@ linear_search_fdes (struct object *ob, const fde *this_fde, _Unwind_Address pc) /* Take care to ignore link-once functions that were removed. In these cases, the function address will be NULL, but if the encoding is smaller than a pointer a true NULL may not - be representable. Assume 0 in the representable bits is NULL. */ + be representable. Assume 0 in the representable bits is NULL. + + For capability targets we must check against the size of an + address, since the size of a pointer includes metadata which does + not determine whether the pointer is NULL or not. */ mask = size_of_encoded_value (encoding); - if (mask < sizeof (void *)) + if (mask < sizeof (_Unwind_Address)) mask = (((_Unwind_Ptr) 1) << (mask << 3)) - 1; else mask = -1; @@ -887,7 +891,7 @@ linear_search_fdes (struct object *ob, const fde *this_fde, _Unwind_Address pc) continue; } - if ((_Unwind_Ptr) pc - pc_begin < pc_range) + if (pc - (_Unwind_Address)pc_begin < (_Unwind_Address)pc_range) return this_fde; } @@ -907,12 +911,12 @@ binary_search_unencoded_fdes (struct object *ob, _Unwind_Address pc) { size_t i = (lo + hi) / 2; const fde *const f = vec->array[i]; - void *pc_begin; + uaddr pc_begin; uaddr pc_range; - memcpy (&pc_begin, (const void * const *) f->pc_begin, sizeof (void *)); + memcpy (&pc_begin, (const uaddr *) f->pc_begin, sizeof (uaddr)); memcpy (&pc_range, (const uaddr *) f->pc_begin + 1, sizeof (uaddr)); - if ((_Unwind_Address)pc < pc_begin) + if (pc < pc_begin) hi = i; else if (pc >= pc_begin + pc_range) lo = i + 1; @@ -944,7 +948,7 @@ binary_search_single_encoding_fdes (struct object *ob, _Unwind_Address pc) if ((_Unwind_Address) pc < pc_begin) hi = i; - else if ((_Unwind_Address) pc >= pc_begin + pc_range) + else if ((_Unwind_Address) pc >= pc_begin + (_Unwind_Address)pc_range) lo = i + 1; else return f; @@ -975,7 +979,7 @@ binary_search_mixed_encoding_fdes (struct object *ob, _Unwind_Address pc) if ((_Unwind_Address) pc < pc_begin) hi = i; - else if ((_Unwind_Address) pc >= pc_begin + pc_range) + else if ((_Unwind_Address) pc >= pc_begin + (_Unwind_Address)pc_range) lo = i + 1; else return f; @@ -996,7 +1000,7 @@ search_object (struct object* ob, _Unwind_Address pc) /* Despite the above comment, the normal reason to get here is that we've not processed this object before. A quick range check is in order. */ - if (pc < ob->pc_begin) + if (pc < (_Unwind_Address)ob->pc_begin) return NULL; } @@ -1054,7 +1058,7 @@ _Unwind_Find_FDE (_Unwind_Address pc, struct dwarf_eh_bases *bases) containing the pc. Note that pc_begin is sorted descending, and we expect objects to be non-overlapping. */ for (ob = seen_objects; ob; ob = ob->next) - if (pc >= ob->pc_begin) + if (pc >= (_Unwind_Address)ob->pc_begin) { f = search_object (ob, pc); if (f) @@ -1097,7 +1101,7 @@ _Unwind_Find_FDE (_Unwind_Address pc, struct dwarf_eh_bases *bases) encoding = get_fde_encoding (f); read_encoded_value_with_base (encoding, base_from_object (encoding, ob), f->pc_begin, &func); - bases->func = func; + bases->func = (void *) func; } return f;
reply other threads:[~2022-03-14 10:35 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20220314103552.DC2F6385E442@sourceware.org \ --to=matmal01@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.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: linkBe 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).