This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH,RFC,V3 0/5] Support for CTF in GCC

On Fri, Jul 5, 2019 at 12:21 AM Indu Bhagat <> wrote:
> On 07/04/2019 03:43 AM, Richard Biener wrote:
> On Thu, Jul 4, 2019 at 2:36 AM Indu Bhagat <> wrote:
> [...]
> RE subset of C : It is true that CTF format currently does leave out a very
> small subset of C like FIXED_POINT as you noted ( CTF does have representation
> for COMPLEX_TYPE, if my code paths culminate to gcc_unreachable () for that, I
> should fix them ).  The end goal is to make it support all of C, and not just a
> subset.
> What about other languages?  GCC supports C++, Ada, Objective-C, Go, D,
> Fortran, Modula-2, BRIG (this list is not necessarily complete and may change
> in the future).
> The format supports C only at this time. Other languages are not on the radar
> yet. However, we have no intrinsic objection to them. Although, languages
> that already have fully-fledged type introspection and interpreted/
> managed languages are probably out of scope, since they already have
> what CTF provides.
> Given it appears to generate only debug info for symbols and no locations
> or whatnot it should be sufficient to introspect the compilation to generate
> the CTF info on the side and then merge it in at link-time.  Which makes
> me wonder if this shouldn't be a plugin for now until it is more complete
> and can be evaluated better (comments in the patches indicate even the
> on-disk format is in flux?).  Adding plugin hook invocations to the three
> places the CTF info generation hooks off should be easy.
> Yes, some bits of the on-disk format are being adapted to make it easier to
> adopt the CTF format across the board. E.g., we recently added CU name in the
> CTF header. As another example, we added CTF_K_SLICE type because there existed
> no way in CTF to represent enum bitfields. For the most part though, CTF format
> has stayed as is.
> I hope the format is versioned at least.
> Yes, the format is versioned. The current version is CTF_VERSION_3.  All these
> format changes I talked about above are a part of CTF_VERSION_3.
> libctf handles backward compatibility for users of CTF in the toolchain; all
> transparently to the user. This means that, in future, when CTF version needs
> to be bumped, libctf will either support older version and/or transparently
> upgrade to the new version for further consumers.
> It also means that the compiler does not always need to change merely because
> the format has changed: (depending on the change) the linker can transparently
> adjust, as will all consumers if they try to read unlinked object files.
> That said, the patch series isn't ready for integration since it will
> crash left and right -- did you bootstrap and run the testsuite
> with -gt?
> Bootstrap and Testsuite : Yes, I have.  On x86_64/linux, sparc64/linux,
>                            aarch64/linux.
> Run testsuite with -gt : Not yet. Believe me, it's on my plate. And I already
>                           regret not having done it sooner :)
> Bootstrap with -gt : Not yet. I should try soon.
> (I have compiled libdtrace-ctf with -gt and parsed the .ctf sections with the
> patch set.)
> About the patch being not ready for integration : Yes, you're right.
> That's why I chose to retain 'RFC' for this patch series as well. I am working
> on issues, testing the compiler, and closing on the open ends in the
> implementation.
> I will refresh the patch series when I have made a meaningful stride ahead. Any
> further suggestions on functional/performance testing will be helpful too.
> What's the functional use of CTF?  Print nice backtraces (without showing
> function argument values)?
> CTF, at this time, is type information for entities at global or file scope.
> This can be used by online debuggers, program tracers (dynamic tracing); More
> generally, it provides type introspection for C programs, with an optional
> library API to allow them to get at their own types quite more easily than
> DWARF. So, the umbrella usecases are - all C programs that want to introspect
> their own types quickly; and applications that want to introspect other
> programs's types quickly.

What makes it superior to DWARF stripped down to the above feature set?

> (Even with the exception of its embedded string table, it is already small
>  enough to  be kept around in stripped binaries so that it can be relied upon
>  to be present.)

So for distributing a program/library for SUSE we usually split the
distribution into two pieces - the binaries and separated debug information.
With CTF we'd then create both, continue stripping out the DWARF information
but keep the CTF in the binaries?

When a program contains CTF only, can gdb do anything to help debugging
of a running program or a core file?  Do you have gdb support in the works?

> We are also extending the format so it is useful for other on-line debugging
> tools, such as backtracers.

So you become more complex similar to DWARF?


> Indu

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]