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