Some of the meta-class proposals (and prototypes!) allow for printf style debugging at compile time. I agree that it would be awful nice if I could debug the compile time constexpr things, or step through overload resolution somehow.

From: SG14 <sg14-bounces_at_[hidden]> On Behalf Of Clément Grégoire
Sent: Thursday, February 14, 2019 2:13 AM
To: Low Latency:Game Dev/Financial/Trading/Simulation/Embedded Devices <sg14_at_[hidden]>
Subject: [EXTERNAL] Re: [SG14] [EXT] Ideas on debug constexpr functions or other functions that have been 100% removed from the EXE

Hi,
I do agree with what's being said, but I think you will get better feedback if you reach SG15 (tooling group) if not done already!

Cheers,
Clément

Le jeu. 14 févr. 2019 à 08:33, Scott Wardle <swardle_at_[hidden]<mailto:swardle_at_[hidden]>> a écrit :
Thanks for the feedback Paul, I fixed the image VPU0SINCOS.png forgot to upload to my web server.

You have the idea exactly.

There are a lot of different versions of the idea I can think of. I have not written a debugger my self but I have worked with people who have back on ps1. I don’t think the debugger runtime is hard to write. As you can see with the python mixed language debuggers it is not that original or do I think that hard.

The compiler side however I don’t know at all and don’t know how to start work on an idea like this. But as I have never seen any ISO papers on debugging maybe I should write a paper anyways :)

Maybe Paul, you are getting at this. I don’t really talk about parameters in the blog post. Each return value has to be mapped to a load of a bunch of parameters and then a call to the code to debug. I should write something on that. It is more than just the debug version of the code.

Would any of these parameters be non-const if the function is “constexper”? I don’t see how, but if they can be then you would need to load a value into this virtual co-processor memory space not so hard either way.

Scott


> On Feb 13, 2019, at 10:40 PM, Paul Hampson <p_hampson_at_[hidden]<mailto:p_hampson_at_[hidden]>> wrote:
>
> I had a 404'd image about 30% down: https://www.swardle.com/sweb/img/VPU0SINCOS.png<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.swardle.com_sweb_img_VPU0SINCOS.png&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=X0uWc7GSCQVpJqj-LfrZbAy5Vy-EMyme5GbyQodZ5H8&s=A_con8RPxCMPVByykG5YYfhKm_RqC4Gs0DGfu6FItZI&e=>
>
> 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_[hidden]<mailto:sg14-bounces_at_[hidden]>> 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]<mailto: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<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.swardle.com_sweb_blog5.html&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=X0uWc7GSCQVpJqj-LfrZbAy5Vy-EMyme5GbyQodZ5H8&s=IQk0_888aKBOp7QPfhrz4wlbrrsPitUZViQ47AjXtLs&e=>
>>
>> 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_lists.isocpp.org<mailto:SG14_at_[hidden]>
>> http://lists.isocpp.org/mailman/listinfo.cgi/sg14<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.isocpp.org_mailman_listinfo.cgi_sg14&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=X0uWc7GSCQVpJqj-LfrZbAy5Vy-EMyme5GbyQodZ5H8&s=bNMfEt-nwdGg7B0i9XNPOeIN9lPnUoe01JEygcHLbAc&e=>
> [wargaming.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__wargaming.net&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=X0uWc7GSCQVpJqj-LfrZbAy5Vy-EMyme5GbyQodZ5H8&s=itWScybEslu8w7rjoFQLVjtuN375stib-CWz7dRtCGY&e=>]
> 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
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]<mailto:SG14_at_[hidden]>
> http://lists.isocpp.org/mailman/listinfo.cgi/sg14<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.isocpp.org_mailman_listinfo.cgi_sg14&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=X0uWc7GSCQVpJqj-LfrZbAy5Vy-EMyme5GbyQodZ5H8&s=bNMfEt-nwdGg7B0i9XNPOeIN9lPnUoe01JEygcHLbAc&e=>

_______________________________________________
SG14 mailing list
SG14_at_[hidden]<mailto:SG14_at_[hidden]>
http://lists.isocpp.org/mailman/listinfo.cgi/sg14<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.isocpp.org_mailman_listinfo.cgi_sg14&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=X0uWc7GSCQVpJqj-LfrZbAy5Vy-EMyme5GbyQodZ5H8&s=bNMfEt-nwdGg7B0i9XNPOeIN9lPnUoe01JEygcHLbAc&e=>