On Wed, May 22, 2019 at 12:34 AM Indu Bhagat <indu.bha...@oracle.com> wrote:
>
> Thanks for your feedback. Comments inline.
>
>
> On 05/21/2019 03:28 AM, Richard Biener wrote:
>
> GCC RFC patch set :
> Patch 1 is a simple addition of a new function lang_GNU_GIMPLE to check for
> GIMPLE frontend.
>
> I don't think you should need this - the GIMPLE "frontend" is intended for
> unit testing only, I wouldn't like it to be exposed more.
>
> When using -gt with -flto, I would still like the CTF hooks to be initialized
> so that CTF can be generated when -flto is used. So the check in toplev.c is
> done to allow only C and GNU GIMPLE. I am fine with doing a string compare
> with the language.hooks string if you suggest to go that way.
I see. Note that starting with GCC 8 type and declaration debug information
(the only you are interested in it seems) for LTO is generated at compile-time
while LTO ("GNU GIMPLE") only amends it with location information. So
I believe you do not want to emit CTF from LTO but from the compilation-stage
driven by the appropriate language frontend which is where debug information
for types and decls is emitted.
>
> One of the main high-level design requirements that is relevant in the context
> of the current GCC patch set is that - CTF and DWARF must be able to co-exist.
> A user may want CTF debug information in isolation or with other debug
> formats.
> A .ctf section is small and unlike other debug sections, ideally should not
> need to be stripped out of the binary/executable.
>
> High-level proposed plan (phase 1) :
> In the next few patches, the functionality to generate contents of the CTF
> section (.ctf) for a single compilation unit will be added.
> Once CTF generation for a single compilation unit stabilizes, LTO and CTF
> generation will be looked at.
>
> Feedback and suggestions welcome.
>
> You probably got asked this question multiple times already, but,
> can CTF information be generated from DWARF instead?
>
> Yes and No :) And that is indeed one of the motivation of the project - to
> allow CTF generation where it's most suited aka the toolchain.
>
> There do exist utilties for generation of CTF from DWARF. For example, one of
> them is the dwarf2ctf in the DTrace Linux distribution. dwarf2ctf works
> offline
> to transform DWARF generated by the compiler into CTF.
>
> A dependency of an external conversion utility for "post-processing" DWARF
> offline poses several problems:
>
> 1. Deployment problems: the converter should be distributed and integrated in
> the build system of the program. This, on occasions, can be intrusive.
> For
> example, in terms of dependencies: the dwarf2ctf converter depends on
> libdwarf from elfutils suite, glib2 (used for the GHashTable), zlib (used
> to
> compress the CTF information) and libctf (which both reads and writes the
> CTF data).
>
> 2. Performance problems: the conversion from DWARF to CTF can take a long
> time,
> especially in big programs such as the Linux kernel.
>
> 3. Maintainability problems: the converter should be maintained in order to
> reflect potential changes in the DWARF generated by the compiler.
>
> 4. Adoption problem: it is difficult for applications to adopt the usage of
> CTF, even if it happens to provide what they need, since it would require
> to
> write a conversion utility or integrate DTrace's.
>
>
>
> The meaning of the CTF acronym suggests that there's nothing
> like locations, registers, etc. but just a representation of the
> types?
>
> Yes. CTF is simply put Type information; no locations, registers etc.
>
>
> Generally we are trying to walk away from supporting multiple
> debug info formats because that gets in the way of being
> more precise from the frontend side. Since DWARF is the
>
>
> With regard to whether the support for CTF imposes infeasible or distinct
> requirements on the frontend - it does not appear to be the case (I have
> been working on CTF generation in GCC for a SINGLE compilation unit; More see
> below). I agree that CTF debug information generation should ideally not
> impose
> additional requirements on the frontend.
>
> defacto standard, extensible and with a rich feature set the
> line of thinking is that other formats (like STABS) can be
> generated by "post-processing" DWARF. Such
> post-processing could happen on the object files or
> on the GCC internal DWARF data structures by
> providing alternate output routines. That is, the mid-term
> design goal is to make DWARF generation the "API"
> for GCC frontends to use when creating high-level
> debug information rather than trying to abstract from
> the debuginfo format via the current debug-hooks or
> the other way around via language-hooks.
>
> I am not sure if I understood the last part very well, so I will state how CTF
> generation is intended to work. Does the following fit the design goal you
> state ?
>
> ( Caveat : I have been working on the functionality to generate CTF for a
> SINGLE
> compilation unit. LTO bits remain. )
>
> So far, there are no additional requirements on the frontend side. CTF hooks
> are wrappers around DWARF debug hooks (much like go-dump hooks, and vms dbg
> hooks). We did notice that GCC does not have the infrastructure to register
> or
> enlist multiple debug hooks; and now from your comments it is clear that this
> is by design. Thanks for clarifying that.
>
> Having said that, I use CTF hooks to go from TREE --> update CTF internal
> structures or output CTF routines depending on the hook (e.g., type_decl or
> finish respectively), rather than changing the dwarf* files with CTF APIs. The
> CTF debug hooks relay control to the DWARF debug hooks at an appropriate
> point.
> TREE input references to the CTF debug hooks are readonly in the context of
> CTF
> generation.
>
> The CTF debug information is kept in a CTF container distinct from the
> frontend
> structures. HashMaps are used to avoid generation of duplicate CTF and to
> book-keep the generated CTF.
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.
Btw, do I read the CTF document posted to the binutils list (but not
cross-referenced
here :/) correctly in that you only want CTF debug for objects defined
in the file and
type information for the types refered to from that? At
dwarf2out_early_finish time
it isn't fully known which symbols will end up being emitted (and with
LTO you only
would know at link time). It seems to me that linker support to garbage collect
unused entries would be the way to go forward (probably easy for the
declarations
but not so for the types)?
Richard.
>
