I had a 404'd image about 30% down: https://www.swardle.com/sweb/img/VPU0SINCOS.png

Thinking about the practicalities of this idea, what if the debug symbol blobs contains unoptimized versions of constexpr, inlined, and other (perhaps #pragma-marked?) functions, which were used for breakpointing? The debug blobs could know that a particular static value is the result of a constexpr call, since the code=>asm mapping must already see something like "call constExpr(X)" => "LOAD accumulator, some constant value". Same for inlining, a function call that maps to something other than a function-call preamble is presumably an inlined function.

Then the debugger could step-through that side-lined code blob, but discard the results (and side-effects?) at the end, and execute the code in the function itself. *Or* it could actually execute the side-lined code, giving you the runtime effect of MSVC's "#pragma optimize(off)" triggered only by placing a breakpoint at a certain point.

Constexpr might be an easier place to start, since we know the side-effects of such a function are limited, and it's really a code->value transform, and they're evaluated down to constants, while inlined and optimised functions are more-arbitrary code->code transforms.

I don't know enough about the internals of debug tables and debuggers to know if this is practical, but it sounds useful for the use-case you've described.

On a side-note, we use mixed C++/Python, and it's a delight when we (occasionally) use the MSVC mixed-mode debugging support for Python, and get mixed Python/C++ stack traces. It sounds like the VPU debugger gave the same thing, so there' definitely mixed-mode debugging traditions around we could leverage.

Not sure if there's a C++ paper in this, probably more of a clang/lld/gdb hackathon opportunity and a nice presentation at CppCon. ^_^

--
Paul “Hampy” Hampson

> -----Original Message-----
> From: SG14 <sg14-bounces_at_lists.isocpp.org> On Behalf Of Scott Wardle
> Sent: Thursday, 14 February 2019 12:26 PM
> To: Low Latency:Game Dev/Financial/Trading/Simulation/Embedded Devices
> <sg14_at_[hidden]>
> Subject: [EXT] [SG14] Ideas on debug constexpr functions or other functions
> that have been 100% removed from the EXE
>
> Hi Everyone,
>
> I was looking through C++ papers and since 2010 (and maybe before) not one
> iso C++ paper has been submitted on debugging. So maybe now is a good
> time to think about how we should debug C++ in a new way.
>
> To that end I had an idea the other day on debugging and wrote a blog on it
> and finally posted it. I don’t see how this would effect the standard but it is
> quality of implementation idea.
>
> If we want to constexpr all of the things it would nice if we could printf debug
> at least. But my idea is maybe we can get the whole debugger to work.
>
> Check it out on my blog. http://www.swardle.com/sweb/blog5.html
>
> Tell me if you have any feedback (spelling grammar or good counter ideas
> that shows why the idea is not posable etc...)
>
> Scott
>
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/sg14
[wargaming.net]
EgzO3mXGcK
This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient and, therefore, may not be retransmitted to any party outside of the recipient's organization without the prior written consent of the sender. If you have received this e-mail in error please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Wargaming.net accepts no liability for any losses or damages resulting from infected e-mail transmissions and viruses in e-mail attachment. kgzO3mXGcg