Re: [patch v6 00/12] branch tracing support for Atom

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Wed, 19 Dec 2012 10:59:37 +0100, Metzger, Markus T wrote:
> At the same time, I wanted some always-on functionality so I didn't have to
> repeatedly enable tracing. I therefore added two different versions: "btrace
> enable [all, <range>]" and "btrace enable auto".

I miss a bit (1) some resulting message saying "New threads will get branch
tracing turned on automatically." and message like "Thread 2 already has
branch tracing turned on." + "Thread 3 branch tracing has been turned on." or
something like that.

And (2) "info btrace" - or with the new move under record - "info record"
where it displays for each thread whether the tracing is on or off and whether
new threads get traced or not.  Maybe it could be also added to "info threads",
if you want to / there is no objection to it.

With existing "record" one knows unfortunately very well whether the tracing
is turned on (=it is very slow).


> Record/replay uses another target on top of the current. It needs to be
> enabled for a running process each time

I do not think it is appropriate for "record".  As it is very slow one wants
to record on the interesting last spot of the execution.

But in principle I think the feature should apply for all (both) record
backends - both the current and the btrace one.


> and it does not allow selective enabling/disabling per thread.

This may be a missing feature for the "record" functionality, it would be also
good to share it with btrace, at least for the CLI interface design for now.


> If I just followed the "target record" command, I would lose the selective
> enabling as well as the automatic enabling

Pushing of the new target could be hooked to to_post_startup_inferior and
to_post_attach, I hope that's enough.


> - and I would risk that not all threads will be traced when running out of
> resources.

I do not understand here which resources may be unavailable and what GDB can
about it.


Thanks,
Jan