Subject: Re: [EXT] Ideas on debug constexpr functions or other functions that have been 100% removed from the EXE
From: Paul Hampson (p_hampson_at_[hidden])
Date: 2019-02-19 05:22:31
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 (note:may be very out of date) to that standard (used extensively in the Linux world, by gcc, llvm and gdb among others).
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 list run by email@example.com
Older Archives on Google Groups