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

[Indu Bhagat <indu.bhagat@oracle.com>]

On 07/04/2019 03:43 AM, Richard Biener wrote:
> On Thu, Jul 4, 2019 at 2:36 AM Indu Bhagat<indu.bhagat@oracle.com>  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.

(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.)

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

Indu