Hello, On Thu, 23 May 2019, Indu Bhagat wrote:
> > OK. So I wonder how difficult it is to emit CTF by walking dwarf2outs own > > data structures? That is, in my view CTF should be emitted by > > dwarf2out_early_finish () (which is also the point LTO type/decl debug > > is generated from). It would be nice to avoid extra bookkeeping data > > structures > > for CTF since those of DWARF should include all necessary information > > already. > > CTF format has some characteristics which make it necessary to "pre-process" > the generated CTF data before asm'ing out into a section. E.g. few cases of > why "pre-processing" CTF is required before asm'ing out : > 1. CTF types do need to be emitted in "some" order : > CTF types can have references to other CTF types. This consequently > implies > that the referenced type must appear BEFORE the referring type. > 2. CTF preamble holds offsets to the various subsections - function info, > variables, data types and CTF string table. To calculate the offsets, the > compiler needs to know the size in bytes of these sub-sections. CTF > representation for some types like structures, functions, enums have > variable length of bytes trailing them (depending on the defintion of the > type). > 3. CTF variable entries need to be placed in the order of the names. > > Because of some of these "features" of the CTF format, the compiler does > need to do a transition from runtime CTF generated data --> CTF binary > data format for a clean and readable code. Sure, but this whole process could still be triggered from within dwarf2out_early_finish, by walking the DWARF tree (instead of getting fed types and decls via hooks) and generating the appropriate CTF data structures. (It's just a possibility, it might end up uglier that using GCC trees) Imagine a world where debug hooks wouldn't exist (which is where we would like to end up in a far away future), how would you then add CTF debug info to the compiler (assuming it already emits DWARF)? You would hook yourself either into the DWARF routines that currently are fed the entities or you would hook yourself into somewhere late in the pipeline where the DWARF debug info is complete and you would generate CTF from that. > So, I think the needs are different enough to vouch for an implementation > segregated from dwarf* codebase. Of course. We are merely discussing of where the triggering of processing starts: debug hooks, or something like: dwarf2out_early_finish() { ... if (ctf) ctf_emit(); } (and then in addition if the current DWARF info would be the source of CTF info, or if it'd be whatever the compiler gives you as trees) The thing is, with debug hooks you'd have to invent a scheme of stacking hooks on top of each other (because we want to generate DWARF and CTF from the same compilation). That seems like a wasted effort when our wish is for the hooks to go away alltogether. Ciao, Michael.