I had a quick play with debugging information output, but neither of the two compilers I had immediately at hand would produce the DW_AT_const_expr tag when told to use Dwarf 4 (the version that added constexpr support), although I did get DW_AT_const_value for the variable holding the result value. Both compilers (clang 4 and gcc 6) were pretty insistent on disappearing the constexpr function entirely. Clang disappeared it even in the non-contexpr case, although I didn’t check the assembly to see if it had *actually* disappeared it, or was just leaving it out of the Dwarf data.

I was using https://github.com/eliben/pyelftools to dump Dwarf, and it doesn’t support Dwarf 5; this version of clang was happy to produce Dwarf 5; gcc silently downgraded to Dwarf 4.

Anyway, it does look like the Dwarf container can hold the information I think it’ll need, as it’s able to point at chunks of code and say “This is a particular inlined method”, with a tag marking whether that was compile-time or run-time evaluated (and the result), which means the real machine code for that inline method is available, unless it is totally elided from the object.

However, I’m not sure if I was asking the wrong questions, or the compilers just don’t bother storing in the Dwarf data when a function was completely elided due to inlining, constexpr or not.

I did think it was interesting that Dwarf considers constexpr functions a subset of inlined functions, and they store them as ‘skeleton’ + ‘instance’. So I guess they were thinking along the same lines as me, that what we’re talking about is a narrower sub-case of inlined-into-incomprehensibility function call trees.

I don’t know what MSVC’s debugging approach is for inline functions, but if it’s similar to Dwarf, then we may have a good starting place to put together a discussion with an achievable outcome.

Anyway, punting this exploration until I get around to setting up a real, up-to-date ELF compilation environment. I suspect ‘if constexpr’ and newer compilers might have more luck getting a DW_AT_const_expr-tagged inline function entry in a Dwarf DB.

--
Paul “TBBle” Hampson

From: SG14 <sg14-bounces_at_[hidden]> On Behalf Of Scott Wardle
Sent: Monday, 18 February 2019 2:05 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

Keeping an eye on what dwarf is doing is a great idea. I have added my self to their mailing list and will lurk for a bit. Looks like the data they have is parameter and return values and the you could get the text of the function I think.

On Feb 17, 2019, at 11:01 AM, Edward Catmur <ecatmur_at_[hidden]<mailto:ecatmur_at_[hidden]>> wrote:

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).

3. http://dwarfstd.org/ShowIssue.php?issue=090107.1
[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