At C++OnSea a few weeks ago I attended a talk[1] by Anastasia Kazakova of
JetBrains that showed off their technology for constexpr and macro
debugging - video available[2]. That's within the context of an IDE (CLion)
but it should help to show what is possible in the present state of affairs.

In the context of tooling for debuggers, I think you might want to look at
the progress (if any) that DWARF are making in adding constexpr support[3]
(note:may be very out of date) to that standard (used extensively in the
Linux world, by gcc, llvm and gdb among others).

1. https://cpponsea.uk/sessions/debug-cpp-without-running.html
2.
https://www.youtube.com/watch?v=ByG6nIm6U24&t=0s&list=PL5XXu3X6L7jtk7-GIVq3-bkKDKDtoagj4&index=5
3. http://dwarfstd.org/ShowIssue.php?issue=090107.1

On Sun, Feb 17, 2019 at 4:03 AM Scott Wardle <swardle_at_[hidden]> wrote:

> Hi Arthur,
>
> Thanks for the feedback.
>
> I think many would agree with you. In fact I often tell most of my game
> programming friends, for the problem you are trying to solve we should just
> work with tools venders directly. Certainly what debugging data is stored
> is not standardized nor I am suggesting it should be.
>
> I think your email Arthur brings up another thing I have been thinking
> about. Why has there never been a paper on debugging?
>
> I think we don’t have papers on debuggers because, while it might be good
> to talk to the C++ cabal about debuggers, mostly debuggers don’t effect
> standard's documentation so these ideas just don’t belong or at least don’t
> get brought up. We should just post them on twitter, or write the vender
> directly etc…
>
> I choose to write SG14 as it was a good small group of customers and also
> maybe some tool venders. I could see if other people liked the idea and if
> there was research in the space I am not aware of. I think SG14 is not a
> bad place to see if this is a real problem in industry or not. If the
> problem was popular enough with customers maybe then it would be worth
> investment by venders. Even if this does not become a paper maybe talking
> about it in SG14, then posting on twitter and emailing the vender is a good
> idea. I mean SG14 is a group made because the C++ standard was having
> trouble talking to some industries after all.
>
> SG15 might have more venders… but I think are more interested in modules
> and build systems. So it was not my first idea, but I have sent the email
> now. My guess is the idea is so big anyways no one will bite unless they
> can see money to be made. So the email chain I bet will die quick no harm
> done.
>
> I don’t really want to sprint plan or manage the development of such a new
> debugger. I wanted to bring up the problem, you can’t debug large parts of
> C++. The set of C++ the can’t be debugged is getting larger and here is an
> idea for part of a solution. I think the full solution is out of scope for
> this group but the fact that we have a problem here and it is getting
> larger is maybe is in scope for SG14. It would be interesting to see how
> many lines of code can have break points in optimized code 10 years ago vs
> 5 years ago vs now. Though I don’t know how to make this data. This would
> feel more like a good paper to me for SG14.
>
> I would love to have your (and other people on SG14) feedback on the
> question, If it does not effect the standard should the idea be talked
> about in SG14? Maybe this is why we will never get an ISO paper on
> debugging? Maybe that is ok. But this communication problem is a very
> interesting problem in its own right.
>
> Scott
>
>
> On Feb 16, 2019, at 5:09 PM, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
> wrote:
>
> Scott, it seems that what you're proposing is not a paper specification
> but rather *a new kind of debugging tool* with its own debug info and so
> on — maybe a plugin for MSVC or gdb or something. I think the proper
> audience to "get interested" in this idea would be *a tool vendor*, not
> WG21. WG21 cannot usefully innovate in tool development. WG21 cannot tell
> tool developers what to build, nor can it magically determine what tools
> will be useful to real programmers. The only way to see if "constexpr
> debugging" would be useful is for someone — a vendor or even a hobbyist —
> to go build this debugging tool and see whether it gets any adoption in the
> field. If it's really useful, it will get adopted.
>
> In terms of getting MSVC interested: Is Herb Sutter listening to this
> thread? ;)
>
> (I do recognize that even if a bunch of people are listening, building a
> new debugger is a humongous and costly task. Let alone building a new
> *kind* of debugger. Still, please don't try to enlist SG15 to do your
> debugger team's sprint planning and product management. Write the product
> internally and then see if gains traction before proposing it.)
>
> –Arthur
>
>
> On Sat, Feb 16, 2019 at 6:48 PM Scott Wardle <swardle_at_[hidden]> wrote:
>
>> Hi Everyone,
>>
>> I updated the blog entry to have a 2nd example. Now it includes a simple
>> inline wrapper function and how I could see virtual co-processor working.
>> I think would be a fair bit harder but I am mostly out of my depth here
>> anyways. I think me talking about the problem is more important than my
>> idea on the solution. Even just the leaf constexpr-ish function idea is
>> not too bad and might be easier. But it shows the limits of the idea
>> better then my last version.
>>
>> http://www.swardle.com/sweb/blog5.html
>>
>> I will see if the SG15 is interested in the idea. It would be nice to
>> know more about the ideas that debugger people are thinking about and how
>> many we can solve the current problem of how bad the debugging experience
>> is in C++.
>>
>> Scott
>>
>>
>> On Feb 15, 2019, at 12:41 AM, Scott Wardle <swardle_at_[hidden]> wrote:
>>
>> Hi Paul,
>>
>> I am in both groups. So I can add SG15 soon. (I wanted to keep an eye
>> on modules and build systems. I didn’t think that maybe debugger should
>> also be in SG15 too.)
>>
>> Before I do I wanted to add a better example that shows a inline wrapper
>> function that calls a non-inline function. I think a lot of company wrap
>> stl or other standard functions. Mostly they inline wrapper should just go
>> away but some change defaults and parameters. This is a harder example but
>> i think is shows more of what would need to be written.
>>
>> My own personal thoughts is I am like to find out why this is hard but I
>> might find some cool ideas on how to fix this problem that are easier to
>> implement. We sure could use some idea like this given our current
>> direction.
>>
>> Scott
>>
>> On Feb 14, 2019, at 23:55, Paul Hampson <p_hampson_at_[hidden]> wrote:
>>
>> I love the idea of a compile-time break-point, for constexpr-evaluated
>> code. That would even work sensibly for maybe-constexpr code, because if
>> you don’t hit it at compile-time, it wasn’t evaluated there for some reason.
>>
>> I feel like this would be a whole new (and exciting!) branch of compiler
>> research. As has been mentioned, this might be an SG15 thing, for SG14
>> we’re more focussed (I guess?) on using it than on specifying/standardising
>> it.
>>
>> I’m not connected with the SG15 group at all, is anyone connected and
>> interested in carrying some of these ideas over there, or bringing in an
>> appropriate joined mail thread? I assume they’ll be joining us on
>> lists.isocpp.org at some point in the near future.
>>
>> --
>> Paul “TBBle” Hampson
>>
>> *From:* SG14 <sg14-bounces_at_[hidden]> *On Behalf Of *Ben Craig
>> *Sent:* Friday, 15 February 2019 1:34 AM
>> *To:* Low Latency:Game Dev/Financial/Trading/Simulation/Embedded Devices
>> <sg14_at_[hidden]>
>> *Subject:* Re: [SG14] [EXT] Ideas on debug constexpr functions or other
>> functions that have been 100% removed from the EXE
>>
>> 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]> 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]>
>> 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]> 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
>> <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_[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 <http://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]
>> > 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]
>> 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]
>> http://lists.isocpp.org/mailman/listinfo.cgi/sg14
>>
>>
>> _______________________________________________
>> SG14 mailing list
>> SG14_at_[hidden]
>> http://lists.isocpp.org/mailman/listinfo.cgi/sg14
>>
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/sg14
>
>
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/sg14
>