On Mon, May 20, 2019 at 7:56 PM Indu Bhagat <indu.bha...@oracle.com> wrote: > > Background : > CTF is the Compact Ansi-C Type Format. It is a format designed to express some > characteristics (specifically Type information) of the data types in a C > program. CTF format is compact and fast; It was originally designed for > use-cases like dynamic tracing, online in-application debugging among others. > > A patch to the binutils mailing list to add libctf is currently under > review (https://sourceware.org/ml/binutils/2019-05/msg00154.html and > https://sourceware.org/ml/binutils/2019-05/msg00212.html). libctf > provides means to create, update, read and manipulate CTF information. > > This GCC patch set is preliminary work and the purpose is to gather comments > and > feedback about CTF support in GCC. > > (For technical introduction into the CTF format, the CTF header or > https://sourceware.org/ml/binutils/2019-04/msg00277.html will be useful.) > > Project Details : > The project aims to add the support for CTF in the GNU toolchain. Adding CTF > support in the GNU toolchain will help the community in developing and > converging the tools and use-cases where a light-weight debug format is > needed. > > De-duplication is a key aspect of the CTF format which ensures its > compactness. > A parallel effort is ongoing to support de-duplication of CTF types at the > link-time. > > In phase 1, we are making the compiler, linker and the debugger (GDB) capable > of handling the CTF format. > > CTF format, in its present form, does not have callsite information. We are > working on this as well. Once the CTF format extensions are agreed upon, the > -gt1 option (see below) will begin to take form, in phase 2 of the project. > > 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. > Patch 2 and Patch 3 set up the framework for CTF support in GCC : > -- Patch 2 adds the new command line option for generating CTF. CTF generation > is enabled in the compiler by specifying an explicit -gt or > -gtLEVEL[LEVEL=1,2] : > > -gtLEVEL > > This is used to request CTF debug information and to specify how much CTF > debug information, LEVEL[=0,1,2] can be specified. If -gt is specified > (with no LEVEL), the default value of LEVEL is 2. > > -gt0 (Level 0) produces no CTF debug information at all. Thus, -gt0 > negates -gt. > > -gt1 (Level 1) produces CTF information for tracebacks only. This includes > CTF callsite information, but does not include type information for other > entities. > > -gt2 (Level 2) produces type information for entities (functions, > variables > etc.) at file-scope or global-scope only. This level of information can be > used by dynamic tracers like DTrace. > > -- Patch 3 adds the CTF debug hooks and initializes them if the required > user-level options are specified. > CTF debug hooks are wrappers around the DWARF debug hooks. > > 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? The meaning of the CTF acronym suggests that there's nothing like locations, registers, etc. but just a representation of the types? 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 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. Richard. > Thanks > > Indu Bhagat (3): > Add new function lang_GNU_GIMPLE > Add CTF command line options : -gtLEVEL > Create CTF debug hooks > > gcc/ChangeLog | 24 ++ > gcc/Makefile.in | 3 + > gcc/common.opt | 9 + > gcc/ctfout.c | 171 +++++++++ > gcc/ctfout.h | 41 +++ > gcc/debug.h | 4 + > gcc/doc/invoke.texi | 16 + > gcc/flag-types.h | 13 + > gcc/gengtype.c | 4 +- > gcc/langhooks.c | 9 + > gcc/langhooks.h | 1 + > gcc/opts.c | 26 ++ > gcc/testsuite/ChangeLog | 7 + > gcc/testsuite/gcc.dg/debug/ctf/ctf-1.c | 6 + > gcc/testsuite/gcc.dg/debug/ctf/ctf-preamble-1.c | 11 + > gcc/testsuite/gcc.dg/debug/ctf/ctf.exp | 41 +++ > gcc/testsuite/gcc.dg/debug/dwarf2-ctf-1.c | 7 + > gcc/toplev.c | 24 ++ > include/ChangeLog | 4 + > include/ctf.h | 471 > ++++++++++++++++++++++++ > 20 files changed, 890 insertions(+), 2 deletions(-) > create mode 100644 gcc/ctfout.c > create mode 100644 gcc/ctfout.h > create mode 100644 gcc/testsuite/gcc.dg/debug/ctf/ctf-1.c > create mode 100644 gcc/testsuite/gcc.dg/debug/ctf/ctf-preamble-1.c > create mode 100644 gcc/testsuite/gcc.dg/debug/ctf/ctf.exp > create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2-ctf-1.c > create mode 100644 include/ctf.h > > -- > 1.8.3.1 >
