C++ Logo

std-proposals

Advanced search

Re: [std-proposals] #include <debug>

From: Oliver Hunt <oliver_at_[hidden]>
Date: Sun, 01 Dec 2024 14:55:38 -0800
> On Dec 1, 2024, at 12:45 PM, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Fri, Nov 29, 2024 at 4:41 PM Thiago Macieira wrote:
>>
>>> Sounds like you take the designers of Control Flow Enforcement as some
>>> sort of authority.
>>
>> Yes. This functionality is already in the market and has been for 2 years (my
>> laptop has it), the hardware functionality cannot be changed any more.
>
>
> I've done a little web-searching on this. Here's what I found about
> Intel Control-flow Enforcement:
>

This is not the only form of control flow integrity, and it is far from the most robust.

On ARM hardware there is pointer authentication which is baked into hardware and has been for approaching a decade. Beyond the implicit hardware ABI, there’s software level ABI

On CHERI hardware code pointers are explicitly tagged for those purposes, and IIRC return addresses are tagged as such by the call instructions themselves.

I’m unclear who this functionality is for?

Debuggers do not need these headers, as a platform debugger already needs to know the platform ABI, in a far deeper way, and across many more languages than just C++.

The methods you’re listing all basically read as examples for which reflection is probably the correct thing to use (http://wg21.link/P2996) rather than an ad-hoc set of accessors for implementation details.

As an errata you need to ensure your examples are using the correct types (or use opaque types rather than trying to present things as function pointers) and you need to clarify which destructor get_address_of_{class,object}_destructor is producing?

—Oliver

Received on 2024-12-01 22:55:54