From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66406 invoked by alias); 11 Jul 2019 16:48:37 -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 66300 invoked by uid 89); 11 Jul 2019 16:48:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=online X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 11 Jul 2019 16:48:14 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x6BGm6wb016920; Thu, 11 Jul 2019 11:48:06 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x6BGm5tJ016919; Thu, 11 Jul 2019 11:48:05 -0500 Date: Thu, 11 Jul 2019 16:54:00 -0000 From: Segher Boessenkool To: Nix Cc: Richard Biener , Indu Bhagat , Jeff Law , Indu Bhagat , GCC Patches Subject: Re: [PATCH,RFC,V3 0/5] Support for CTF in GCC Message-ID: <20190711164805.GH14074@gate.crashing.org> References: <0086f709-b8e5-fc73-1679-4a39e0f4e673@redhat.com> <755cd109-f02b-3ebd-762f-71ae570bf21a@oracle.com> <87k1cwwd37.fsf@esperi.org.uk> <20190709232514.GB14074@gate.crashing.org> <87bly0rc5t.fsf@esperi.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87bly0rc5t.fsf@esperi.org.uk> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00906.txt.bz2 On Thu, Jul 11, 2019 at 01:25:18PM +0100, Nix wrote: > On 10 Jul 2019, Segher Boessenkool spake thusly: > > > On Fri, Jul 05, 2019 at 07:28:12PM +0100, Nix wrote: > >> On 5 Jul 2019, Richard Biener said: > >> > >> > On Fri, Jul 5, 2019 at 12:21 AM Indu Bhagat wrote: > >> >> 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? > >> > >> Increased compactness. > > > > Does CTF support something like -fasynchronous-unwind-tables? You need > > that to have any sane debugging on many platforms. Without it, you > > even have only partial backtraces, on most architectures/ABIs anyway. > > The backtrace section is still being designed, so it could! There is > certainly nothing intrinsically preventing it. Am I right that this > stuff works by ensuring that the arg->location picture is consistent at > all times, between every instruction, rather than just at function > calls, i.e. tracking all register moves done by the compiler, even > transiently? Yes, something like that. You get unwind tables that are valid at each instruction boundary. This is esp. important for the return address, without that backtraces are broken. > Because that sounds doable, given that the compiler is > doing the hard work of identifying such locations anyway (it has to for > DWARF -fasynchronous-unwind-tables, right?). Yes, every backend outputs DWARF info semi-manually for this. You have some work to do if you want to use this for CTF. > It seems essential to do this in any case if you want to get correct > args for the function the user is actually stopped at: there's no > requirement that the user is stopped at a function call! Yes. You need the asynchronous option only if you need this info at any possible point in a program -- but quite a few things do need it everywhere ;-) Segher