From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40873 invoked by alias); 5 Jul 2019 11:17:05 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 40865 invoked by uid 89); 5 Jul 2019 11:17:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=superior, HX-Google-Smtp-Source:APXvYqx, SUSE, suse X-HELO: mail-lf1-f65.google.com Received: from mail-lf1-f65.google.com (HELO mail-lf1-f65.google.com) (209.85.167.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 05 Jul 2019 11:17:03 +0000 Received: by mail-lf1-f65.google.com with SMTP id p197so6100352lfa.2 for ; Fri, 05 Jul 2019 04:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tiKBguY2pDbkTLuDmQzvOPuAjuyZDs6CD50NPfSKXng=; b=BU01Zf9KjEn9WZ2u0gtte65xV5GF/yajFXLWml5PAKyxGm8fhBVtKtBnkhCTWi4QrA e4wFzPQRCDRUehT7PgtGGOtcPwWg1y+mopohqM7UGjaKHKBjZxtyPHqsKJ53lwhH9EIu zG9gHSRjBuBWkvsM2A1MAHuvBQOWwfQF1YUc2SJGETHOc8JoJjoC4uV72hEMQGmYPhMO D51I5nn4e635qqCOdHxBPfp+miGF4gvYSp4kCf54TkofgdgeqpBz06vmyujkxUrv9V2f Yl2qZdJvPUbV6dPPBKJWot8h2YZg29RUkaPK6hQKOnzetga1w1SsoE2+rMghbuQWgjS8 xuFg== MIME-Version: 1.0 References: <1561617445-9328-1-git-send-email-indu.bhagat@oracle.com> <0086f709-b8e5-fc73-1679-4a39e0f4e673@redhat.com> <755cd109-f02b-3ebd-762f-71ae570bf21a@oracle.com> In-Reply-To: <755cd109-f02b-3ebd-762f-71ae570bf21a@oracle.com> From: Richard Biener Date: Fri, 05 Jul 2019 11:25:00 -0000 Message-ID: Subject: Re: [PATCH,RFC,V3 0/5] Support for CTF in GCC To: Indu Bhagat Cc: Jeff Law , Indu Bhagat , GCC Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00427.txt.bz2 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? Richard. > > Indu