This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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 ;-)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]