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

Nix nix@esperi.org.uk
Thu Jul 11 12:59:00 GMT 2019


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 <indu.bhagat@oracle.com> 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? 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?).

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!



More information about the Gcc-patches mailing list