RE: [PATCH v2 5/7] btrace, gdbserver: remove the to_supports_btrace target method

Maciej W. Rozycki
2018-02-28T10:29:44Z

Hi Markus,

> > With the change description you have also overrun our 74-column limit:
> > <https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-
> > Standards#Column_limits>.
> > NB due to how `git log' etc. indents descriptions I prefer to stay within
> > 72 columns with my own changes for a better visual effect, though you are of
> > course free to use your own judgement here as long as you're within 74 columns.
>
> Actually, the hard limit is 80 columns. I've been using that, so far, and from
> looking at other files in gdb/ it looks like others were using the 80 columns limit,
> as well.

Well other people doing it wrong is not an excuse I am afraid. With
source files it is at least bearable, however as I wrote `git log' etc.
indent descriptions by 4 characters, which means that as soon as you are
beyond 76 columns lines get wrapped making text really hard to follow.

Take your recent commit de65820cd69a as an example. Its description
renders like this on my screen:

In gdb.btrace/buffer-size.exp we explicitly ask for the BTS recording format
.
This may lead to spurious fails on systems where PT is being used by some ot
her
process at the same time.

Set both PT and BTS buffer sizes to 1 and check that whatever recording form
at
is used will use a 4KB buffer.

-- is this how you wanted it to look like?

If you disagree, then please discuss and get a consensus on an update to
the rules set in our wiki. They are there for a reason and please look
for past discussions as to why they have been set like they are now.

> > Thanks for confirming. Is there going to be any difference here for
> > non-x86 targets that needs to be verified?
>
> They're supposed to work the same way. I.e. older gdbservers won't
> advertise the packets and newer GDB's hence won't use them. And
> newer gdbservers would advertise the packets and, with this patch,
> fail on every request with "E.Target does not support branch tracing".
>
> Let me check that once for both directions just to be sure.

Great, thanks!

Maciej