On Fri, Jul 5, 2019 at 12:21 AM Indu Bhagat <indu.bha...@oracle.com> wrote: > > 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.
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? Richard. > > Indu
