C++ Logo


Advanced search

Subject: Re: [EXT] Ideas on debug constexpr functions or other functions that have been 100% removed from the EXE
From: Clément Grégoire (clem.gregoire.cg_at_[hidden])
Date: 2019-02-14 02:12:46

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!


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
> >
> > 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
> >>
> >> 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
> 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]
> > http://lists.isocpp.org/mailman/listinfo.cgi/sg14
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/sg14

SG14 list run by herb.sutter at gmail.com

Older Archives on Google Groups