[all-commits] [llvm/llvm-project] d5f84e: [libc++abi] Handle catch null pointer-to-object (#...

[Iain Sandoe via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: d5f84e6121f0d0cc8984dccc1774ce9ddb7168c4
      https://github.com/llvm/llvm-project/commit/d5f84e6121f0d0cc8984dccc1774ce9ddb7168c4
  Author: Iain Sandoe <iain at sandoe.co.uk>
  Date:   2024-01-08 (Mon, 08 Jan 2024)

  Changed paths:
    M libcxxabi/src/private_typeinfo.cpp
    M libcxxabi/src/private_typeinfo.h
    A libcxxabi/test/catch_null_pointer_to_object_pr64953.pass.cpp

  Log Message:
  -----------
  [libc++abi] Handle catch null pointer-to-object (#68076)

This addresses cases (currently failing) where we throw a null
pointer-to-object and fixes #64953.

We are trying to satisfy the following bullet from the C++ ABI 15.3:

* the handler is of type cv1 T* cv2 and E is a pointer type that can be
converted to the type of the handler by either or both of:

  - a standard pointer conversion (4.10 [conv.ptr]) not involving
    conversions to private or protected or ambiguous classes.

  - a qualification conversion.

The existing implementation assesses the ambiguity of bases by computing
the offsets to them; ambiguous cases are then when the same base appears
at different offsets. The computation of offset includes indirecting
through the vtables to find the offsets to virtual bases.

When the thrown pointer points to a real object, this is quite efficient
since, if the base is found, and it is not ambiguous and on a public
path, the offset is needed to return the adjusted pointer (and the
indirections are not particularly expensive to compute).

However, when we throw a null pointer-to-object, this scheme is no
longer applicable (and the code currently bypasses the relevant
computations, leading to the incorrect catches reported in the issue).

-----

The solution proposed here takes a composite approach:

1. When the pointer-to-object points to a real instance (well, at least,
it is determined to be non-null), we use the existing scheme.

2. When the pointer-to-object is null:

  * We note that there is no real object.
  * When we are processing non-virtual bases, we continue to compute the
    offsets, but for a notional dummy object based at 0. This is OK, since
    we never need to access the object content for non-virtual bases.
  * When we are processing a path with one or more virtual bases, we
    remember a cookie corresponding to the inner-most virtual base found so
    far (and set the notional offset to 0). Offsets to inner non-virtual
    bases are then computed as normal.

A base is then ambiguous iff:
* There is a recorded virtual base cookie and that is different from the
  current one or,
* The non-virtual base offsets differ.

When a handler for a pointer succeeds in catching a base pointer for a
thrown null pointer-to-object, we still return a nullptr (so the
adjustment to the pointer is not required and need not be computed).

Since we noted that there was no object when starting the search for
ambiguous bases, we know that we can skip the pointer adjustment.

This was originally uploaded as https://reviews.llvm.org/D158769.
Fixes #64953