Subject: Re: [EXT] Ideas on debug constexpr functions or other functions that have been 100% removed from the EXE
From: Edward Catmur (ecatmur_at_[hidden])
Date: 2019-02-17 13:01:13
At C++OnSea a few weeks ago I attended a talk by Anastasia Kazakova of
JetBrains that showed off their technology for constexpr and macro
debugging - video available. 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
(note:may be very out of date) to that standard (used extensively in the
Linux world, by gcc, llvm and gdb among others).
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
> 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.
> On Feb 16, 2019, at 5:09 PM, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
> 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.)
> 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.
>> 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++.
>> 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
>> 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
>> 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
>> *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
>> *Sent:* Thursday, February 14, 2019 2:13 AM
>> *To:* Low Latency:Game Dev/Financial/Trading/Simulation/Embedded Devices
>> *Subject:* [EXTERNAL] Re: [SG14] [EXT] Ideas on debug constexpr
>> functions or other functions that have been 100% removed from the EXE
>> 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
>> > On Feb 13, 2019, at 10:40 PM, Paul Hampson <p_hampson_at_[hidden]>
>> > I had a 404'd image about 30% down:
>> > 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
>> > 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
>> >> that have been 100% removed from the EXE
>> >> Hi Everyone,
>> >> I was looking through C++ papers and since 2010 (and maybe before) not
>> >> 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
>> >> 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
>> > 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
>> SG14 mailing list
>> SG14 mailing list
>> SG14 mailing list
> SG14 mailing list
> SG14 mailing list
SG14 list run by herb.sutter at gmail.com
Older Archives on Google Groups