I think for constexpr, the parameters would indeed all by constant, so the compiler could record exactly what you need to see in the debugger to simulate what it did at compile-time. Similarly for `if constexpr`, it has to be compile-time evaluated because the other code-branches may be unable to have code generated for them given the current parameters and template instantiations.

Once you're looking at doing the same "stepability" support for inlined code or even just code where O3 is totally incomprehensible, then you do get actual parameters you need to see flow through the code at run-time.

--
Paul “Hampy” Hampson

> -----Original Message-----
> From: SG14 <sg14-bounces_at_lists.isocpp.org> On Behalf Of Scott Wardle
> Sent: Thursday, 14 February 2019 6:34 PM
> 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
>
> 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_wargaming.net> wrote:
> >
> > 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_lists.isocpp.org
> >> 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
> > _______________________________________________
> > SG14 mailing list
> > SG14_at_lists.isocpp.org
> > http://lists.isocpp.org/mailman/listinfo.cgi/sg14
>
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/sg14