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 <indu.bha...@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?
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
