From: "Maciej W. Rozycki" <macro@mips.com>
To: "Metzger, Markus T" <markus.t.metzger@intel.com>
Cc: Andreas Arnez <arnez@linux.vnet.ibm.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: RE: [PATCH v2 5/7] btrace, gdbserver: remove the to_supports_btrace target method
Date: Wed, 28 Feb 2018 10:29:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.00.1802280946150.3553@tp.orcam.me.uk> (raw)
In-Reply-To: <A78C989F6D9628469189715575E55B236964DA03@IRSMSX104.ger.corp.intel.com>
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
next prev parent reply other threads:[~2018-02-28 10:29 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-26 14:14 [PATCH v2 0/7] improve btrace enable error reporting Markus Metzger
2018-01-26 14:14 ` [PATCH v2 4/7] btrace, gdbserver: use exceptions to convey btrace enable/disable errors Markus Metzger
2018-01-26 14:14 ` [PATCH v2 6/7] btrace: improve enable error messages Markus Metzger
2018-01-26 14:14 ` [PATCH v2 2/7] common: add scoped_mmap Markus Metzger
2018-01-26 14:14 ` [PATCH v2 1/7] common: add scoped_fd Markus Metzger
2018-02-13 16:48 ` Yao Qi
2018-02-13 17:28 ` Metzger, Markus T
2018-02-14 15:22 ` Yao Qi
2018-02-14 17:26 ` Metzger, Markus T
2018-02-19 15:28 ` Metzger, Markus T
2018-02-20 10:12 ` Yao Qi
2018-02-20 10:46 ` Metzger, Markus T
2018-01-26 14:14 ` [PATCH v2 3/7] btrace: prepare for throwing exceptions when enabling btrace Markus Metzger
2018-01-26 14:14 ` [PATCH v2 5/7] btrace, gdbserver: remove the to_supports_btrace target method Markus Metzger
2018-02-24 16:51 ` Maciej W. Rozycki
2018-02-26 13:08 ` Metzger, Markus T
2018-02-26 19:30 ` Andreas Arnez
2018-02-26 21:58 ` Maciej W. Rozycki
2018-02-27 10:57 ` Metzger, Markus T
2018-02-27 15:32 ` Maciej W. Rozycki
2018-02-27 18:14 ` Metzger, Markus T
2018-02-28 10:29 ` Maciej W. Rozycki [this message]
2018-02-28 11:09 ` Maciej W. Rozycki
2018-02-28 11:24 ` Metzger, Markus T
2018-02-28 12:53 ` Metzger, Markus T
2018-02-28 15:55 ` Maciej W. Rozycki
2018-02-28 16:08 ` Eli Zaretskii
2018-02-28 12:00 ` Yao Qi
2018-02-28 16:27 ` Sergio Durigan Junior
2018-03-01 11:33 ` Metzger, Markus T
2018-03-01 19:27 ` Sergio Durigan Junior
2018-03-05 12:14 ` Yao Qi
[not found] ` <87lgf64i24.fsf@redhat.com>
2018-03-06 9:02 ` Yao Qi
2018-03-06 16:32 ` Sergio Durigan Junior
2018-03-01 19:34 ` Maciej W. Rozycki
2018-02-06 16:28 ` [PATCH v2 0/7] improve btrace enable error reporting Pedro Alves
2018-02-07 10:41 ` Metzger, Markus T
2018-02-07 12:11 ` Pedro Alves
2018-02-08 10:40 ` Metzger, Markus T
[not found] ` <9ce0c90a-5c71-0a7d-3779-f826369a95ec@redhat.com>
2018-02-08 13:49 ` Metzger, Markus T
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.00.1802280946150.3553@tp.orcam.me.uk \
--to=macro@mips.com \
--cc=arnez@linux.vnet.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=markus.t.metzger@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox