C++ Logo

sg14

Advanced search

Re: [SG14] [EXT] Ideas on debug constexpr functions or other functions that have been 100% removed from the EXE

From: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Date: Sat, 16 Feb 2019 20:09:01 -0500
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
>

Received on 2019-02-16 19:09:04